Just to be sure what I'm asking is clear, why does this:
Code: Select all
$arr = array("foo" => "bar", 12 => true);
Code: Select all
$arr = array("bar", true);
Moderator: General Moderators
Code: Select all
$arr = array("foo" => "bar", 12 => true);
Code: Select all
$arr = array("bar", true);
Code: Select all
$array[1] = transform($array[0]);Code: Select all
$array["title_urlsafe"] = transform($array["title"]);Code: Select all
// not tested syntactically accurate, but you'll get the idea
$myArray= array(someValue, someValue, someValue, ...);
for ($i = 0; $i < count ($images); $i++)
{
echo "$myArray[$i]<br>\n";
};
Code: Select all
// not tested syntactically accurate, but you'll get the idea
$images = array();
// your structure is *right here*
$query = "SELECT `Path`, `SizeX`, `SizeY`, `AltText` FROM `Images` WHERE etc etc etc";
// for the purposes of abbreviation, assume that the query was run and the results fetched here. The result being:
// [[Path, SizeX, SizeY, AltText], [Path, SizeX, SizeY, AltText], ...]
for ($i = 0; $i < count ($images); $i++)
{
echo "<img src=\"{$myArray[$i][0]}\" w=\"{$myArray[$i][1]}\" h=\"{$myArray[$i][2]}\" alt=\"{$myArray[$i][3]}\"><br>";
};
// I guess this is just as valid, though it precludes the possibilitly of doing special things on specific indexes. I guess a counter can work around it though:
forEach $images as $image
{
echo "<img src=\"$image[Path]\" w=\"$image[SizeX]\" h=\"$image[SizeY]\" alt=\"$image[AltText]\"><br>";
};
Code: Select all
echo "<img src=\"{$myArray[$i][0]}\" w=\"{$myArray[$i][1]}\" h=\"{$myArray[$i][2]}\" alt=\"{$myArray[$i][3]}\"><br>";And what if the array was populated somewhere not close by? Another function? Another file entirely? If I know that $myArray has items from a database table then I immediately know what the fields are. With indexes I have to find where the array was generated and see which order the fields were chosen in. If you SELECT A,B,C you cannot easily change the fields without going through every single file looking for whether that array gets used. Should you use string keys you can add or move fields without caring about anything.ColonelSandersLite wrote:As far as knowing what's in the array goes, you should already know this! It's spelled out clearly when you load the array in the first place.
Yes, that is my inclination, too. PHP provides lots of alternatives, nobody is going to make you use associative arrays if you believe you can do better with numeric indexed arrarys. Use whichever you want.tasairis wrote:Also, why not skip the whole discussion and just use functions like mysql_fetch_row that satisfy everybody?
Simple, "`AltText` FROM `Images`" as defined in line 6.tasairis wrote:Looking at that (and putting aside the HTML markup itself) I have no clue what's in $myArray. The first dimension is no doubt a straight list of items, but the second dimension is totally vague. What's #3? Alt text? Image title? Name associated with the image? Static text?Code: Select all
echo "<img src=\"{$myArray[$i][0]}\" w=\"{$myArray[$i][1]}\" h=\"{$myArray[$i][2]}\" alt=\"{$myArray[$i][3]}\"><br>";
If you don't know the return format of your function, you're in trouble if you don't find out regardless. In the case of both, you still have to look it up when you're writing fresh code or debugging something with the array. I guess with named indexes you can print_r the array to find out, but I honestly don't find that to be more convenient than just looking up a few lines.tasairis wrote:And what if the array was populated somewhere not close by? Another function? Another file entirely? If I know that $myArray has items from a database table then I immediately know what the fields are. With indexes I have to find where the array was generated and see which order the fields were chosen in.
I can see this point in some instances, but it's not quite true in all cases. It's not hard to imagine loops and such, that are there to process an array, getting thrown by unexpected values regardless of how it's indexed. This sounds to me like it's the highway to bug city.tasairis wrote:Should you use string keys you can add or move fields without caring about anything.
This is exactly what I want to know here. In what tangible way are they more powerful? Of course I'm already using numeric indexes, such as is returned by mysql_fetch_row(), but what I want to know, is whether or not there is any real reason I should change this practice. As long as you keep the spaghetti code to a minimum, it's just not hard to look up and see how the array was indexed, or check the return value of the function you got it from. I also maintain that numeric arrays are less prone to having a typo in the key as well. I would *really* like to see some example of something a named key can do which a numeric key cannot, but I really doubt such a thing exists.tasairis wrote:When appropriate, associative arrays are always more powerful than indexed arrays.
Code: Select all
if ($config['someFeature']['enabled']) {
// do something
}
Code: Select all
if ($config[X]['enabled']) {
// do something
}
Code: Select all
if ($cfg_someFeature == 'enabled') {
// do something
}
Code: Select all
foreach ($array as $key => $value)
{
// code...
}
Weirdan wrote:Simple and expressive:Code: Select all
if ($config['someFeature']['enabled']) { // do something }
Code: Select all
define('someFeature', 0);
define('enabled', 1);
define('disabled', 0);
if ($config[someFeature][enabled]) {
// do something
}
What's with E_NOTICE? My original code wouldn't raise any notices, unless the config branch happened to be undefined. But in this case yours would throw a notice as well.VladSun wrote:it's even without E_NOTICE raised)
You do realize that it would require to create lots of constants for even moderately complex adhoc config structure, right? And you wouldn't be able to easily inspect parts of the structure with built in tools like var_dump() or print_r(). And there's high chance of collisions when those constants are reused on different levels.It's even less error prone ... which I think is the most important ...
I would tend to agree there. It would just be much much easier to ditch arrays and use straight variable names instead of doing that.Weirdan wrote:You do realize that it would require to create lots of constantsIt's even less error prone ... which I think is the most important ...
Code: Select all
// config file
$cfg_someFeature = 0;
$cfg_someOtherFeature = 1;
$cfg_someDifferentFeature = 1;
$cfg_aFeature = 0;
$cfg_something = 1;
$cfg_youGetTheIdea = ?;
//test you use elsewhere
if ($cfg_someFeature == 1)
{
// dosomething
};