Det betyder at funktionen modtager en reference til variablen $form i stedet for en kopi af variablen $form. På den måde kan funktionen modificere $form direkte.
Er det mig der er forkert på den, eller er & tegnet ikke deprecated i de nye versioner af PHP? Hvis det er, så er det vel lidt ligegyldigt... et gammelt levn som man helst bør undgå.
& operatoren gør det muligt at ændre PHPs behandling af variable, på en måde så at andre typer variable opfører sig lidt som objekter, på den måde at hvis du ændrer informationen et sted, så ændrer du det for alle som har en reference til informationen.
Det er et godt alternativ til globale variable for et system som Drupal hvor mange komponenter blander sig i variable og deres værdier. Computervidenskaben har mange forskellige tilgange til hvordan den slags skal foregå, og i PHP har man valget mellem “Call by value” og “Call by reference” (her er den lange forklaring på Wikipedia).
Som Jens siger er det deprecated at bruge det i funktionskald, men ikke i funktionsdefinitioner. Det skyldes det kan gøre programmet meget svært at gennemskue, hvis en funktion i nogen tilfælde arbejder med referencer og andre ikke.
I Drupal er det påkrævet at bruge referencer via & i funktionsdeklararationen hvis du vil have glæde af hooks som f.eks hook_form_alter(). Det er altid anført i dokumentationen, hvis en hook bruger referencer, og det kan anbefales kun at bruge referencer i disse tilfælde, da disse altid vil resultere i side effects, som iflg. computervidenskaben er et onde (om end til tider et nødvendigt et af slagsen).
Tak for den gode forklaring. Det undrede mig også meget da jeg startede med Drupal hvorfor man havde så mange funktioner der ændrede i arrays uden at returnere dem igen. Det giver selvfølgelig meget mere mening nu :)
wulff
16. juli 2010 - 9:32
Permalink
Det betyder at funktionen
Det betyder at funktionen modtager en reference til variablen $form i stedet for en kopi af variablen $form. På den måde kan funktionen modificere $form direkte.
Læs mere om referencer i manualen: http://php.net/manual/en/language.references.pass.php
Morten Najbjerg
26. juli 2010 - 10:29
Permalink
Deprecated
Er det mig der er forkert på den, eller er & tegnet ikke deprecated i de nye versioner af PHP? Hvis det er, så er det vel lidt ligegyldigt... et gammelt levn som man helst bør undgå.
beltofte
26. juli 2010 - 11:51
Permalink
Ja og nej. Hvis det benyttes
Ja og nej. Hvis det benyttes i kaldet af en funktion er det depcrecated. Eksempel:
Korrekt:
function foo(&$var) { }Forkert:
Hvis du gør det vil du få en warning hvis allow_call_time_pass_reference er slået til i php.ini.Morten Najbjerg
26. juli 2010 - 19:26
Permalink
Nåh ja!
Det er da også rigtigt... :)
mikl
26. juli 2010 - 19:43
Permalink
Det kommer an på hvem man spørger…
& operatoren gør det muligt at ændre PHPs behandling af variable, på en måde så at andre typer variable opfører sig lidt som objekter, på den måde at hvis du ændrer informationen et sted, så ændrer du det for alle som har en reference til informationen.
Det er et godt alternativ til globale variable for et system som Drupal hvor mange komponenter blander sig i variable og deres værdier. Computervidenskaben har mange forskellige tilgange til hvordan den slags skal foregå, og i PHP har man valget mellem “Call by value” og “Call by reference” (her er den lange forklaring på Wikipedia).
Som Jens siger er det deprecated at bruge det i funktionskald, men ikke i funktionsdefinitioner. Det skyldes det kan gøre programmet meget svært at gennemskue, hvis en funktion i nogen tilfælde arbejder med referencer og andre ikke.
I Drupal er det påkrævet at bruge referencer via
&i funktionsdeklararationen hvis du vil have glæde af hooks som f.eks hook_form_alter(). Det er altid anført i dokumentationen, hvis en hook bruger referencer, og det kan anbefales kun at bruge referencer i disse tilfælde, da disse altid vil resultere i side effects, som iflg. computervidenskaben er et onde (om end til tider et nødvendigt et af slagsen).Morten Najbjerg
2. august 2010 - 11:08
Permalink
Tak
Hej Mikl
Tak for den gode forklaring. Det undrede mig også meget da jeg startede med Drupal hvorfor man havde så mange funktioner der ændrede i arrays uden at returnere dem igen. Det giver selvfølgelig meget mere mening nu :)