[PHP] Array met foreach() wijzigen

[verytallman]

Ik heb een leuke array, dit doorloop ik met een foreach om 1 waarde te veranderen steeds:

PHP:

foreach ($arrResults as $result) {
   $result['datum'] = convertDate($result['datum']);
   echo $result['datum'] // Geeft goede datum
}

Maar bij het uitpoepen van $arrResults na deze foreach is de datum niet veranderd.....

Dit werkt daarentegen wel:

PHP:

$i = 0;
foreach ($arrResults as $result) {
   $arrResults[$i]['datum'] = convertDate($result['datum']);
   $i++;
}

Ik vind een oplossing altijd wel leuk, maar waarom werkt de eerste oplossing niet?

[.oisyn]

omdat $result een kopie is van de entry in de array, niet een referentie daarnaar.

Bovendien kun je dan beter dit doen:

PHP:

foreach ($arrResults as $i => $result)
   $arrResults[$i]['datum'] = convertDate($result['datum']);

Dan werkt het ook voor arrays met keys die niet van 0 naar count-1 lopen, of strings zijn.

[prototype]

Even ter aanvulling op .oisyn, $result is een lokale variabele binnen de scope van de compoundstatement (tussen de braces van de foreach). Het is daarbij een kopie en niet de referentie ernaar dus. Als je de referentie ernaar wil kan je dat misschien ook op deze manier:

PHP:

foreach($arrResults as &$result)
{
    $result['datum'] = convertDate($result['datum']);
}

Let daarbij op de & bij $result. Niet getest, kan ook gigantisch niet werken.

[ Voor 8% gewijzigd door prototype op 21-10-2006 23:28 ]

[Raynman]

prototype schreef op zaterdag 21 oktober 2006 @ 23:26:
$result is een lokale variabele binnen de scope van de compoundstatement (tussen de braces van de foreach)

Is dat zo? Classes en functies hebben wel een eigen scope, maar voor zover ik weet bestaan dergelijke beperkingen niet bij andere dingen. Is het niet gewoon een normale variabele, wat dus betekent dat $result na de foreach een kopie van het laatste element uit de array is?

[.oisyn]

prototype schreef op zaterdag 21 oktober 2006 @ 23:26:
Even ter aanvulling op .oisyn, $result is een lokale variabele binnen de scope van de compoundstatement (tussen de braces van de foreach)

Dus? Ik zie niet helemaal in wat scope ermee te maken heeft, het is niet dat hij de variabele $result na de lus nog gebruikt . Daarnaast, is dat nieuw in PHP5? In php4 had je geen dergelijke scopes.

Let daarbij op de & bij $result. Niet getest, kan ook gigantisch niet werken.

Had ik nog even geprobeerd voor het posten, maar het werkte iig niet in PHP4, geen idee hoe het zit met 5

[ Voor 9% gewijzigd door .oisyn op 21-10-2006 23:42 ]

[user109731]

Klopt, reference gebruiken is nieuw in PHP 5:

quote: http://nl3.php.net/foreach

As of PHP 5, you can easily modify array's elements by preceding $value with &. This will assign reference instead of copying the value.

PHP:

$arr = array(1, 2, 3, 4);
foreach ($arr as &$value) {
   $value = $value * 2;
}
// $arr is now array(2, 4, 6, 8)

[Shadowman]

prototype schreef op zaterdag 21 oktober 2006 @ 23:26:

PHP:

foreach($arrResults as &$result)
{
    $result['datum'] = convertDate($result['datum']);
}

Let daarbij op de & bij $result. Niet getest, kan ook gigantisch niet werken.

Dat werkt wel (enkel in php5), maar je moet er wel ontzettend goed mee uitkijken:

PHP:

$array = array(1,2,3);
foreach( $array as &$item ) { }
print_r( $array );
foreach( $array as $item ) { }
print_r( $array );

+ uitvoer:

Array
(
    [0] => 1
    [1] => 2
    [2] => 3
)
Array
(
    [0] => 1
    [1] => 2
    [2] => 2
)

^ de uitvoer hiervan is expected behaviour.

@raynman: $result is idd een kopie naar het laatste item van de array.

[ Voor 0% gewijzigd door Shadowman op 21-10-2006 23:47 . Reden: verwijzing die niet klopte... ]

[verytallman]

Wat een service ! En dat op de zaterdag avond

Dit werkt trouwens goed in PHP5:

PHP:

foreach($arrResults as &$result) {
    $result['datum'] = convertDate($result['datum']);
}

Echter, de oplossing in de eerste post van .iosyn vind ik wel beter.

[BasieP]

Shadowman schreef op zaterdag 21 oktober 2006 @ 23:46:
[...]

Dat werkt wel (enkel in php5), maar je moet er wel ontzettend goed mee uitkijken:

PHP:

$array = array(1,2,3);
foreach( $array as &$item ) { }
print_r( $array );
foreach( $array as $item ) { }
print_r( $array );

+ uitvoer:

Array
(
    [0] => 1
    [1] => 2
    [2] => 3
)
Array
(
    [0] => 1
    [1] => 2
    [2] => 2
)

^ de uitvoer hiervan is expected behaviour.

hey die volg ik niet helemaal.. waarom is die 2de print_r opeens de content van het laatste element in $array veranderd?
je doet foreach, maar daarin doe je niks met $item, laat staan met $array..

[user109731]

Ik denk dat dit ongeveer de reden is: $item is eerst een reference, en dat blijftie ook na de eerste foreach(). Daarna ken je de nieuwe array positie toe aan $item, zodat je toch die reference (die nog stond ingesteld op de positie 2) veranderd zeg maar...

Maar dan zou ik verwachten datie geen 2 maar 0 of 1 is?

[Raynman]

Grote prutser schreef op zaterdag 21 oktober 2006 @ 23:59:
Ik denk dat dit ongeveer de reden is: $item is eerst een reference, en dat blijftie ook na de eerste foreach(). Daarna ken je de nieuwe array positie toe aan $item, zodat je toch die reference (die nog stond ingesteld op de positie 2) veranderd zeg maar...

Maar dan zou ik verwachten datie geen 2 maar 0 of 1 is?

$item is inderdaad een reference naar $array[2] na het doorlopen van de eerste foreach. Dan komt de tweede foreach die steeds de waarde van een element aan $item toekent/daarnaar kopieert.

$array[2] krijgt (via reference $item) dus achtereenvolgens de waarden van $array[0], $array[1] en $array[2]. Dit zijn resp. 1, 2 en 2 (want bij de tweede iteratie wordt de waarde van $array[1] (=2) gekopieerd naar $array[2] en de laatste iteratie doet weinig, nl. $array[2]=$array[2] (waarde van het laatste element (inmiddels veranderd) wordt door foreach toegekend aan $item (=reference))). De waarde 3 is dus overschreven met waarde 2.

Hoop dat dit duidelijk is.

[ Voor 5% gewijzigd door Raynman op 22-10-2006 00:11 ]

[.oisyn]

Allejezus, je gaat toch niet vertellen dat dat ook by-design is he?
.edit: ja en nee, de meningen in de PHP crew lijken verdeeld

[ Voor 44% gewijzigd door .oisyn op 22-10-2006 00:59 ]

[DizzyWeb]

.oisyn schreef op zondag 22 oktober 2006 @ 00:49:
Allejezus, je gaat toch niet vertellen dat dat ook by-design is he?
.edit: ja en nee, de meningen in de PHP crew lijken verdeeld

Aan de andere kant, waarom niet? Waarom zou een reference opeens geen reference meer zijn?
Ik vind het opzich wel logisch. Vreselijk onhandig, maar wel logisch.

[Janoz]

Tja, wat is logisch. In principe is alles wat een computer doet logisch. Maar dit is toch duidelijk het logische gevolg van een erg brakke ontwerpbeslissing. Omdat ze niet hebben nagedacht over het niet binnen een scope houden van een lokaal gedefinieerde variabele kan deze blijkbaar binnen een geheel losstaande scope weer worden bewerkt. In dit kleine voorbeeldje kun je pas na flink analitisch werk achterhalen waarom dit fout gaat, maar in een praktijk script zal een dergelijke bug een stuk lastiger op te sporen zijn.

Maar goed, ik heb weer een item om aan mijn php lijstje toe te voegen.

[.oisyn]

DizzyWeb schreef op zondag 22 oktober 2006 @ 01:01:
[...]

Aan de andere kant, waarom niet? Waarom zou een reference opeens geen reference meer zijn?

Omdat je met de foreach bepaalt dat het geen reference is. Maar omdat hij "toevallig" al bestaat als reference blijft het een reference. Het komt er dus op neer dat je in feite voor elke foreach altijd een unset moet doen van de iterator om bugs te voorkomen, zit jij daar op te wachten?

[prototype]

Ai, het is niet zo'n goed idee volgens mij meer voor mij om in het vervolg te generaliseren van hoe het ZOU moeten zijn en hoe PHP het doet. Weer wat geleerd mbt de scoping van variabelen in PHP iig, en ook ik kan weer wat aan mijn PHP lijstje toevoegen.

[MBV]

Die fout hierboven is een direct gevolg van een heel fout design in PHP: je mag iets wat in een scope werd gebruikt, erna nog net zo vrolijk gebruiken. Enige uitzondering daarop is een functie. Voorbeeldje wat wel makkelijk is, maar niet zoals het hoort:

PHP:

//begin script
for ($i = 0; $i < 10; $i++)
{
  $result[] = 85;
}
print_r($result);

$result is alleen bekend binnen de for-loop, en zou dus geen resultaat moeten geven bij de print_r. Maar omdat PHP dat soort ongein toestaat, krijg je vaak van dit soort code:

PHP:

if (conditie()) $array = functie();

foreach ($array as $key => $value)
...

Wat in sommige gevallen zo'n mooie warning geeft dat $array geen array is. Of erger natuurlijk.

Vroegah, toen we nog in C programmeerden, kon je nog dit soort trucs uithalen om het geheugengebruik iets te verminderen:

C:

 
int function()
{
  int c = getkey(); //of hoe heette dat ding ook al weer?
  {
    int d = 85;
    if (c < d) return 1;
  }
  //doe iets
}

[ Voor 19% gewijzigd door MBV op 22-10-2006 12:58 ]

[MBV]

Bedankt voor het aangeven van de fout in foreach. Ik had de volgende code:

PHP:

require("XML/Tree.php");

//$pictureXML is een node
foreach($exif as $key => $value)
{
    $exif =& $pictureXML->addChild('exif', '',array('test'=>'blaat'));
    $exif->addChild('hasName', $key, 'http://www.w3.org/2001/XMLSchema#string');
    $exif->addChild('hasEValue', $value, 'http://www.w3.org/2001/XMLSchema#string');
}

En waarom geeft hij nou een error dat zijn child geen object is? Dat had ik anders nooit gevonden...
een unset en het is opgelost, ipv 3 maanden debuggen. Met dank aan de scopes van PHP

[.oisyn]

Tja, blockscoping is nou niet echt per se een must voor een taal imho. Niet dat ze de rest van de scoping op orde hebben, maar dat is hier het punt niet. Ik denk dat je bij het ontwerpen van een taal er prima voor kunt kiezen om geen blockscoping te ondersteunen, maar zorg er dan voor dat zo'n foreach ook doet wat je verwacht (en zorg er als programmeur voor dat je nooit dangling references laat hangen)

[Genoil]

Wat overigens dan in PHP5 ook nog zo is, is dat als $result een object zou zijn, je helemaal geen & hoeft te gebruiken omdat objecten by design wel altijd by-reference worden genomen...

[Wim-Bart]

Inderdaad heel vreemd gedrag. Maar de constructie:

PHP:

$aTest= array(0,0,0,0,0);
foreach ($aTest as $iIndex => &$iValue) { $iValue= $iIndex * $iIndex }

Werkt goed. Alleen de code:

PHP:

$aTest= array(0,0,0,0,0);
foreach ($aTest as $iIndex => &$iValue) { $iValue= $iIndex * $iIndex; }
foreach ($aTest as $iIndex => &$iValue) { $iValue= $iIndex * $iIndex; $iValue= $iValue * $iIndex; }

Lijkt niet goed te werken en raakt soms de weg kwijt, maar ook niet altijd wat heel vreemd is. Daarom gebruik ik het niet meer. Zoals hiervoor reeds geschreven is de constructie:

PHP:

$aTest= array(0,0,0,0,0);
foreach ($aTest as $iIndex => $iValue) 
{ 
  $aTest[$iKey]= $iIndex * $iIndex; 
}
foreach ($aTest as $iIndex => $iValue)
{ 
  $iTemp = $iIndex * $iIndex;
  $iTemp = $iTemp * $iIndex; 
  $aTest[$iKey]= $iTemp;
}

meer code, maar werkt vanzelfsprekend en betrouwbaar. Bij hele grote array's kost het veel meer tijd.

Maar de foreach statement heeft andere rare gedragingen en is niet consistent in uitvoer.

PHP:

$aTest= array(0,1,"E",3,4);
foreach ($aTest as $iIndex => &$iValue) { if ($iValue==="E") unset($iValue); }

of

PHP:

$aTest= array(0,1,"E",3,4);
foreach ($aTest as $iIndex => &$iValue) { if ($iValue==="E") unset($aTest[$iIndex]); }

zijn leuke zaken die raar doen.

[.oisyn]

Wat is "raar doen"? Logisch dat een unset($iValue) niet werkt, daarmee unset je iValue, niet waar hij naar wijst (gelukkig maar).

[Grijze Vos]

MBV schreef op zondag 22 oktober 2006 @ 12:54:
Die fout hierboven is een direct gevolg van een heel fout design in PHP: je mag iets wat in een scope werd gebruikt, erna nog net zo vrolijk gebruiken. Enige uitzondering daarop is een functie. Voorbeeldje wat wel makkelijk is, maar niet zoals het hoort:

PHP:

//begin script
for ($i = 0; $i < 10; $i++)
{
  $result[] = 85;
}
print_r($result);

Dat is dan ook bijzonder slecht gecode van jou. Omdat PHP dynamisch typeert worden aangemaakte variabelen in de scope van de functie geplaatst. Vind ik best begrijpelijk dat ze dat zo doen hoor.

Maar goed, in ieder geval had jij je array moeten initialiseren, en dat gebeurt buiten de scope van je for-loopje, en dan zou er ongeacht van eventuelere strictere scoping regels een en ander wel goed gebeurd zijn. Je array niet intialiseren is vreselijk slecht, doe maar eens foreach() over een lege variabele...

PHP:

//begin script
result = array();
for ($i = 0; $i < 10; $i++)
{
  $result[] = 85;
}
print_r($result);

[edit]
Ik ben het er overigens wel mee eens dat bij for en foreach loopjes die references wel gecleared mogen worden, maar goed, sommige "koppige" mensen bij php zien dat zo te zien niet zitten.

[ Voor 8% gewijzigd door Grijze Vos op 24-10-2006 14:11 ]

[MBV]

@grijze vos: ik gaf ook bewust een slecht voorbeeld, van hoe het niet moet. Ik zie het helaas dagelijks, een zeker persoon die hier veel code heeft geschreven dacht er nooit zo veel over na. error_reporting(E_ALL) levert niet voor niets 3 pagina's aan waarschuwingen op in een gemiddelde pagina

Probleem is het slechte ontwerp van de taal, wat ivm backwards compatibility niet meer te fixen is...

[ Voor 15% gewijzigd door MBV op 24-10-2006 14:35 ]

[prototype]

MBV schreef op dinsdag 24 oktober 2006 @ 14:35:

Probleem is het slechte ontwerp van de taal, wat ivm backwards compatibility niet meer te fixen is...

Het is wel te fixen, alleen niet zo makkelijk meer. Je kan het niet meer van de ene op de andere dag 'fixen', omdat je daarmee 9/10 php developers ermee benadeelt die dit waarschijnlijk als een voordeel zien. Maar zolang de PHP developers dit niet onderkennen als een bug, en beweren dat het by design is, zal een fix er ook niet voor inzitten. Ik denk dat men vroeger niet zag aankomen welke richting ze met PHP opgingen, i.e. van enkel een webtaaltje naar een meer 'general purpose' aanpak. En nu zitten ze met de gebakken peren, want dingen die vroeger handig leken, blijken nu met het gekozen pad toch niet zo handig te zijn. Goed voorbeeld is method overloading. Zo is het mogelijk om default waarden toe te kennen in de signatuur van de methode voor de parameters, waardoor het onmogelijk is geworden voor de interpreter om de juiste methode te resolven. Of dit by design is weet ik niet, wat achterlijker is, is dat je zulke zaken nu zelf moet 'simuleren', i.e. de parameters tellen en evalueren en zelf delegeren. Ik heb zelf even naar aanleiding van dit topic het e.e.a. erover geblogged iig, vooral omdat ik dit zelf zo over het hoofd zou hebben gezien door de verkeerde aanname mbt scopes in PHP. Bedankt TS en posters iig voor deze leerzame ervaring

[Grijze Vos]

Ze hadden bij php5 gewoon een harde lijn moeten trekken en moeten zeggen "sorry, geen bw compatibility".

Dan hadden ze redelijk wat ranzige dingetjes uit php5 kunnen laten.

[MBV]

prototype schreef op dinsdag 24 oktober 2006 @ 14:44:
[...]
En nu zitten ze met de gebakken peren

Nee, met http://pear.php.net

, want dingen die vroeger handig leken, blijken nu met het gekozen pad toch niet zo handig te zijn. Goed voorbeeld is method overloading. Zo is het mogelijk om default waarden toe te kennen in de signatuur van de methode voor de parameters, waardoor het onmogelijk is geworden voor de interpreter om de juiste methode te resolven. Of dit by design is weet ik niet, wat achterlijker is, is dat je zulke zaken nu zelf moet 'simuleren', i.e. de parameters tellen en evalueren en zelf delegeren.

Zit in elke taal. Of je taal Java, C++ of C heet, method overloading is lastig. Maar in C++/Java valt het minder op, dankzij strakkere typering

Ik heb zelf even naar aanleiding van dit topic het e.e.a. erover geblogged iig, vooral omdat ik dit zelf zo over het hoofd zou hebben gezien door de verkeerde aanname mbt scopes in PHP. Bedankt TS en posters iig voor deze leerzame ervaring

Graag gedaan

[prototype]

MBV schreef op dinsdag 24 oktober 2006 @ 15:24:
[...]

Zit in elke taal. Of je taal Java, C++ of C heet, method overloading is lastig. Maar in C++/Java valt het minder op, dankzij strakkere typering

Nu weet ik dat C++/C wel default parameter values ondersteund, maar Java afaik niet, of heb ik weer wat gemist?

[NMe]

Grijze Vos schreef op dinsdag 24 oktober 2006 @ 14:57:
Ze hadden bij php5 gewoon een harde lijn moeten trekken en moeten zeggen "sorry, geen bw compatibility".

Dan hadden ze redelijk wat ranzige dingetjes uit php5 kunnen laten.

offtopic:
Gelukkig zeggen ze dat bij PHP6 wel. Nouja, binnen de grenzen van het redelijke, maar er worden heel wat ranzige dingen uit gegooid.

[MBV]

gaan ze dan eindelijk logische functienamen introduceren, en namespaces? Vast niet

prototype schreef op dinsdag 24 oktober 2006 @ 15:36:
[...]


Nu weet ik dat C++/C wel default parameter values ondersteund, maar Java afaik niet, of heb ik weer wat gemist?

Hmm, je hebt gelijk. Naja, ik bedoelde meer zoiets als 'veel talen' In veel gevallen is het makkelijk, en als het je in de weg zit gebruik je de default parameters toch niet?

[ Voor 70% gewijzigd door MBV op 24-10-2006 16:09 ]

[prototype]

MBV schreef op dinsdag 24 oktober 2006 @ 16:03:
gaan ze dan eindelijk logische functienamen introduceren, en namespaces? Vast niet

Nouja, het ene is heel eenvoudig op te lossen door het andere te introduceren. Met de komst van namespaces zou men alle 'deprecated' functienamen onder een bepaalde namespace kunnen brengen. Voor backwards compatibility zou dit dan betekenen dat men die betreffende namespace dient te importeren. Op den duur kan je dat natuurlijk helemaal laten vervallen, maar het een is iig dus eenvoudig op te lossen door het andere mechanisme te introduceren Het zou dan bij wijze van spreken 1 import statement vereisen, maar beter is natuurlijk gewoon meteen je functienamen omschrijven naar de nieuwe consistente varianten ervan

Hmm, je hebt gelijk. Naja, ik bedoelde meer zoiets als 'veel talen' In veel gevallen is het makkelijk, en als het je in de weg zit gebruik je de default parameters toch niet?

Nouja, ik weet dus niet of dat zo eenvoudig ligt. Ik ben zelf nog lang geen C++ guru, maar wat ik me dan afvraag is hoe deze dan zo'n default parameter value goed kan resolven. Voor de record, ik heb nooit default parameter values hoeven te gebruiken dus weet ook niet wat dit oplevert Bij gebrek aan een C++ compiler hier vraag ik het dus even hier. B.v.:

C++:

void bla(int i=2);
void bla();

Hoe kan de compiler dit ooit nog goed resolven wanneer ik een method call bla() doe? Krijg ik nu dan een mooie error/warning?

[16:22] <Creepy> blaat.c: In function 'int main()':
[16:22] <Creepy> blaat.c:15: error: call of overloaded 'bla()' is ambiguous
[16:22] <Creepy> blaat.c:3: note: candidates are: void bla(int)
[16:22] <Creepy> blaat.c:8: note: void bla()
[16:22] <Creepy> overigens

Thanks creepy

[ Voor 40% gewijzigd door prototype op 24-10-2006 16:24 ]

[Creepy]

Een mooie warning dus (zoals het hoort wat mij betreft)

met GCC
blaat.c:15: error: call of overloaded 'bla()' is ambiguous
blaat.c:3: note: candidates are: void bla(int)
blaat.c:8: note: void bla()

Maar C++ kan dat ook prima doen omdat het niet met de backwards compatibiliteit zit omdat C en geen overloading en geen default parameters ondersteunt.

* Creepy mept prototype. Ik kan hier ook posten

[ Voor 6% gewijzigd door Creepy op 24-10-2006 16:26 ]

[.oisyn]

MBV schreef op dinsdag 24 oktober 2006 @ 15:24:
Zit in elke taal. Of je taal Java, C++ of C heet, method overloading is lastig. Maar in C++/Java valt het minder op, dankzij strakkere typering

En C++ (de rest niet - zij ondersteunen geen default arguments) slingert je om de oren met ambiguity errors als een overload conflict met een andere methode waar je default parameters voor gebruikt. Ambiguity is echter iets waar PHP nog nooit van gehoord heeft - die kiest liever een van de twee dan dat hij een error geeft.

.edit: moet f5'en voor ik reply

[ Voor 8% gewijzigd door .oisyn op 24-10-2006 16:44 ]

[MBV]

ambiguity is iets wat niet bestaat in PHP. Je pakt toch sowieso de laatste, wat is daar dan ambiguous aan?

Ik zou af en toe graag een optie mee willen geven, bijv zeggen dat een parameter Integer moet zijn. Oftewel, ik ga eens naar ASP .NET en JSP kijken