[PHP] Functie naam dynamisch samenstellen

[Sjoerd]

Ik weet nog dat ik in vb.net altijd heel graag had dat dit werkten en ben er nu achter gekomen dat het in php werkt:

code:

//functie experimentje
$temp="vandaag";
$func="get_bezoekers_".$temp;
echo $func();

Hij voert het gewoon perfect uit zonder zeuren.
Aangezien ik niet super ervaren ben met php, mag ik dit gewoon gebruiken, zijn er meer die dit doen?

Ik heb programmeer ervaring en weet dus ook dat dit een "heel erg vieze" manier van programmeren is.
Maar het lost gewoon zoveel op

Jullie mening? Gebruiken of negeren en gewoon lekker een halve pagina langere code neer zetten

[Reinier]

Ik ben echt benieuwd waarom je dit zou willen. In jouw voorbeeld kan je toch prima "vandaag" als parameter aan je functie meegeven? Verklaar eens waarom je dit handig zou vinden

[Depress]

Als je met OOP werkt is dit misschien wel handig:

PHP:

if(method_exists($this, '_do_'.$var))
    call_user_func(array($this, '_do_'.$var));

[Sjoerd]

omdat ik zeg maar 8 functies had gemaakt die allemaal met dezelfde naam begonnen

en op het einde vandaag,gisteren,week,maand,...

Maar inderdaad dat van extra code is misschien wel overdreven kan natuurlijk idd als paramter meegeven en dan een switch maken binnenin die functie. vind het gewoon erg raar dat het werkt en vroeg me dus af of het wel of niet mocht

[MBV]

Gewoon een goed ontwerp maken, zodat je dit soort smerige dingen niet nodig hebt. Waarom denk je dat niet hele volksstammen ${'array_achtig_ding_'+$i} gebruiken? Het kan toch?

[djluc]

Het wordt niet echt als schoolvoorbeeld van mooie code gezien. In sommige gevallen kan het handig zijn maar meestal verhuld het een fout ontwerp van het stuk code.

[eamelink]

Het is niet raar, en het is ook niet vies

Met is_callable kan je van tevoren nog even checken of de functie wel aanroepbaar is

[MBV]

djluc schreef op donderdag 05 juli 2007 @ 22:09:
Het wordt niet echt als schoolvoorbeeld van mooie code gezien. In sommige gevallen kan het handig zijn maar meestal verhuld het een fout ontwerp van het stuk code.

Ik ken een goed voorbeeld: een template-engine, waarbij je een variabel script uit kan voeren (geen user input uiteraard). Maar dit voorbeeld van de TS is zou fout als het maar wezen kan.

eamelink schreef op donderdag 05 juli 2007 @ 22:09:
Het is niet raar, en het is ook niet vies

Met is_callable kan je van tevoren nog even checken of de functie wel aanroepbaar is

Ehm, nee? get_bezoekers_$xxx is niet vies? Als ik me niet heel sterk vergis is dat een functie die 5x is gecopy/paste, met een aangepaste conditie ergens. Dat noem ik nou vies

[eamelink]

In dit voorbeeld is het waarschijnlijk niet de beste oplossing nee, maar variabele functie of methodenamen in het algemeen zijn zeker niet vies

[MBV]

waarom zoiets ranzigs gebruiken als je ook polymorfisme hebt? Zelfs die template-engine had zonder variabele functienamen gekund: alleen de klassenaam hoeft variabel te zijn. Misschien is dat wel wat overkill, maar in bijna alle gevallen is een variabele functienaam een kwestie van een verkeerd ontwerp.

[ Voor 27% gewijzigd door MBV op 05-07-2007 23:20 ]

[Verwijderd]

Polymorfisme in PHP? Kan dat???
En hoe vies zijn variabele method namen?

Toevallig ben ik nu bezig een stack based parser om te zetten van Delphi naar C#. De functies die die parser ondersteunt zijn in de Delphi implementatie function pointers, maar in managed C# is dat geen optie meer. In C# heb ik dat nu omgezet naar strings die de functienaam bevatten, en via reflection haal ik er de bijbehorende method bij. Werkt prima, en door dit in de parser class zelf af te handelen blijft 't ook nog goed beheersbaar.

Eigenlijk vergelijkbaar met variabele method namen in PHP, alleen beter afgeschermd binnen de class die er gebruik van maakt...

(en ik weet dat reflection kostbaar is, maar de C# implementatie moet 100% compatibel zijn met de Delphi versie)

[MBV]

zie het laatste voorbeeldje: http://php.net/oop
zelfs in PHP4 zat dat dus al.

Reflection is inderdaad ongeveer hetzelfde, en met een parser kan ik me voorstellen dat het nodig is. Maar in de meeste gevallen wil je het wel vermijden: je code wordt er zo ongelofelijk ondoorzichtig door. "waar wordt deze functie aangeroepen?" kan je niet meer beantwoorden.

[T-MOB]

Mja, het enige waar ik het structureel in toepas zijn recursieve functies en voor callback-achtige functionaliteit.

PHP:

//recursie
recursiveFunction() {
    $recurse = __FUNCTION__;

    //do something

    $recurse();
}

//callback
class Collection {

    function find($method, $val) {
        while($entry = $this->each();
        if (method_exists($entry, $method) && $entry->$method() == $val) {
            $this->reset();
            return $entry;
        }
        return NULL;
    }
}

Het eerste omdat het imho duidelijker is en omdat ik te vaak de fout heb gemaakt om de functienaam te veranderen en de recursieve call te vergeten
Het tweede omdat het herbruikbaarheid verhoogt. De find() methode is nuttig in alle classes die collection extenden.

[ Voor 0% gewijzigd door T-MOB op 06-07-2007 01:36 . Reden: Moeilijk, Nederlandsch... ]

[drm]

Ik gebruik ook regelmatig variabele functienamen, maar ik gebruik het nooit om functienamen samen te stellen, eigenlijk.

Toepassing van T-MOB vind ik een hele goeie. Ik gebruik het zelf bijvoorbeeld in situaties als:

PHP:

class RecordSet{
   function getCallbackTemplateVars ( $functionName, $param1 = null, $param2 = null ) {
      $ret = array ();
      $args = func_get_args ();
      array_shift ( $args );
      while ( $record = $this->next () ) {
         if ( !method_exists ( $record, $functionName ) ) {
            trigger_error ( 'Expected valid callback!' );
            return null;
         }
         $ret[$record->getId ()] = call_user_func_array ( array ( $record, $functionName ), $args );
      }
      return $ret;
   }
}

i.c.m. smarty, dan

[MBV]

T-MOB schreef op vrijdag 06 juli 2007 @ 01:34:
Mja, het enige waar ik het structureel in toepas zijn recursieve functies en voor callback-achtige functionaliteit.

PHP:

//recursie
recursiveFunction() {
    $recurse = __FUNCTION__;

    //do something

    $recurse();
}

//callback
class Collection {

    function find($method, $val) {
        while($entry = $this->each();
        if (method_exists($entry, $method) && $entry->$method() == $val) {
            $this->reset();
            return $entry;
        }
        return NULL;
    }
}

Het eerste omdat het imho duidelijker is en omdat ik te vaak de fout heb gemaakt om de functienaam te veranderen en de recursieve call te vergeten
Het tweede omdat het herbruikbaarheid verhoogt. De find() methode is nuttig in alle classes die collection extenden.

De eerste is voor mij onnodig: als ik een functienaam verander, controleer ik sowieso altijd met grep waar hij allemaal wordt aangeroepen.
De tweede is dus een soort functor? Er zijn mooiere manieren om dat op te lossen, maar voor PHP kan het ermee door ik heb dit zelf ooit opgelost door een comparison-functie te schrijven, en aan usort mee te geven.

[Woy]

Verwijderd schreef op donderdag 05 juli 2007 @ 23:59:
Toevallig ben ik nu bezig een stack based parser om te zetten van Delphi naar C#. De functies die die parser ondersteunt zijn in de Delphi implementatie function pointers, maar in managed C# is dat geen optie meer. In C# heb ik dat nu omgezet naar strings die de functienaam bevatten, en via reflection haal ik er de bijbehorende method bij. Werkt prima, en door dit in de parser class zelf af te handelen blijft 't ook nog goed beheersbaar.

offtopic:
Kan je dat niet gewoon met Delegates oplossen?

[eamelink]

MBV schreef op donderdag 05 juli 2007 @ 23:20:
waarom zoiets ranzigs gebruiken als je ook polymorfisme hebt?

Begin nu eerst eens uit te leggen waarom het 'ranzig' is

Zelfs die template-engine had zonder variabele functienamen gekund: alleen de klassenaam hoeft variabel te zijn.

Tuurlijk, vrijwel alles kan je _zonder_ bepaalde functionaliteit? Maar ik zit niet te programmeren om het als het kan zonder normale functionaliteit te doen omdat dat 'ranzig' is . Ik neem het liefst gewoon de handigste manier

Misschien is dat wel wat overkill, maar in bijna alle gevallen is een variabele functienaam een kwestie van een verkeerd ontwerp.

Ik heb een oude UBB parser, waarin ik tags kan toevoegen door gewoon in de class een methode ubb_tagnaam() aan te maken. Als die functie bestaat, dan is [tagnaam] dus een valide tag. Tevens kan die functie dan meteen de html fabrieken die bij de [tagnaam] tag hoort. Lijkt me weinig mis mee

Momenteel ben ik met een framework bezig waar urls gemapt worden aan controllers en actions. Dan wordt ook gewoon gecheckt of het een geldige controller is, en dan aangemaakt met new $controller_name(), om vervolgens de action aan te roepen met $c->$actionname(). Ik weet niet hoe ik dat op een elegante manier anders zou moeten doen

[MBV]

Ik vind het smerig, omdat je magic toevoegt aan een naam die je in principe nergens terug kan vinden. Hetzelfde probleem als $$string: je moet er met een boog omheen lopen, tot je echt niet anders kan (of nog ranzigere dingen gaat uitvinden )

[eamelink]

Dat is zo, maar er zijn natuurlijk zat situaties te bedenken waar de naam gewoon nog niet bekend is tijdens het devven. De maker van de UBB class weet niet wat voor tags er ondersteund moeten gaan worden, de maker van het framework kent de controllers en actions niet.

Variabele stringnamen vind ik wat dat betreft een heel stuk dubieuzer, binnen een enkele scope zijn de namen van je variabelen in principe altijd bekend

[koekiemonster]

Kan je niet gewoon 1 funcie maken die op basis van je meegegeven variable aan de slag gaat?

function doeIets($var1, $var2){

switch ($var2) {
case 0:
echo "i equals 0";
break;
case 1:
echo "i equals 1";
break;
case 2:
echo "i equals 2";
break;
}


}

[Verwijderd]

koekiemonster schreef op vrijdag 06 juli 2007 @ 16:20:
Kan je niet gewoon 1 funcie maken die op basis van je meegegeven variable aan de slag gaat?

function doeIets($var1, $var2){

switch ($var2) {
case 0:
echo "i equals 0";
break;
case 1:
echo "i equals 1";
break;
case 2:
echo "i equals 2";
break;
}


}

Waarom zou je dát willen doen?
Dan kan je gelijk functies op zich overboord gooien.

Het lijkt me dan toch wel stukken beter om je code logisch te groeperen in functies en die functies dan dynamisch aan te roepen (indien nodig).

[Creepy]

eamelink schreef op vrijdag 06 juli 2007 @ 12:54:
Dat is zo, maar er zijn natuurlijk zat situaties te bedenken waar de naam gewoon nog niet bekend is tijdens het devven. De maker van de UBB class weet niet wat voor tags er ondersteund moeten gaan worden, de maker van het framework kent de controllers en actions niet.

Met behulp van functie pointers, polymorphisme of interfaces kan je prima zaken uitbreidbaar houden zonder daar je hoeft terug te vallen op variabele functienamen en er zal ook nog wel een design pattern voor wezen. Als dat allemaal geen optie is dan zou ik pas gaan nadenken over variabele functienamen.

[NMe]

Creepy schreef op vrijdag 06 juli 2007 @ 16:40:
[...]

Met behulp van functie pointers,

Functiepointers in PHP? Voor zover ik weet kan dat alleen op de manier zoals in de TS aangegeven; een string opbouwen en die stringvariabele aanroepen als functie. In zekere mate zul je dit dus toch nodig kunnen hebben in PHP, al moet ik zeggen dat ik dit soort constructies zelf graag vermijd waar mogelijk. IMO wordt de code er iets minder overzichtelijk van als je functies op deze manier gaat gebruiken.

[Creepy]

* Creepy mept -NME-. Was jij niet op vakantie? En let op de "Als dat allemaal geen optie is dan zou ik pas gaan nadenken over variabele functienamen". Mijn opmerking is dan ook niet alleen op PHP gericht.

[NMe]

Creepy schreef op vrijdag 06 juli 2007 @ 17:25:
Mijn opmerking is dan ook niet alleen op PHP gericht.

Dit topic wel.

Enneh, I'm back.

[Verwijderd]

rwb schreef op vrijdag 06 juli 2007 @ 12:12:

offtopic:
Kan je dat niet gewoon met Delegates oplossen?

Had ook gekund, en was in feite m'n eerste optie. En wanneer ik een volledig nieuwe parser in C# zou schrijven, zou ik zeker ook voor delegates kiezen.
Maar bij deze port van een Delphi implementatie komt reflection het dichtst in de buurt van de function pointer afhandeling van Delphi. Met als voordeel dat de structuur van beide parsers vrijwel gelijk kon blijven, en m'n collega's die overweg kunnen met de Delphi versie ook snel hun weg kunnen vinden in de C# versie.

[MBV]

Verwijderd schreef op vrijdag 06 juli 2007 @ 16:38:
[...]

Waarom zou je dát willen doen?
Dan kan je gelijk functies op zich overboord gooien.

Het lijkt me dan toch wel stukken beter om je code logisch te groeperen in functies en die functies dan dynamisch aan te roepen (indien nodig).

Omdat het programma van de ts er waarschijnlijk zo uit zou kunnen zien:

PHP:

function get_bezoekers ($filter)
{
  $sql = "SELECT * FROM bezoekers WHERE ";
  switch ($filter)
  {
    case 'vandaag': 
       $sql .= 'date >= VAGE_FUNCTIE_VOOR_VANDAAG';
       break;
    case 'maand': 
       $sql .= 'date >= VAGE_FUNCTIE_VOOR_MAAND';
       break;
    default:
       die('unexpected case');
  }
  $db &= database::getDB();//singleton ;)
  $db->execute($sql);
}

Dat is toch veel handiger dan 2x die query copy/pasten, en veel makkelijker uit te breiden?

[Gonadan]

eamelink schreef op vrijdag 06 juli 2007 @ 12:18:
Ik heb een oude UBB parser, waarin ik tags kan toevoegen door gewoon in de class een methode ubb_tagnaam() aan te maken. Als die functie bestaat, dan is [tagnaam] dus een valide tag. Tevens kan die functie dan meteen de html fabrieken die bij de [tagnaam] tag hoort. Lijkt me weinig mis mee

Om eerlijk te zijn lijkt mij dat eerder een ontwerp wat dus niet makkelijk uit te breiden was en is het met variabele functienamen opgelost. In mijn ogen niet echt netjes.
Zelf zou ik bijvoorbeeld liever de tags met hun html equivalent declareren in een array. En dat waarschijnlijk nog in een include. Dan is het makkelijk aan te passen en oneindig uit te breiden.

[Sjoerd]

MBV schreef op zaterdag 07 juli 2007 @ 10:24:
[...]

Omdat het programma van de ts er waarschijnlijk zo uit zou kunnen zien:

PHP:

function get_bezoekers ($filter)
{
  $sql = "SELECT * FROM bezoekers WHERE ";
  switch ($filter)
  {
    case 'vandaag': 
       $sql .= 'date >= VAGE_FUNCTIE_VOOR_VANDAAG';
       break;
    case 'maand': 
       $sql .= 'date >= VAGE_FUNCTIE_VOOR_MAAND';
       break;
    default:
       die('unexpected case');
  }
  $db &= database::getDB();//singleton ;)
  $db->execute($sql);
}

Dat is toch veel handiger dan 2x die query copy/pasten, en veel makkelijker uit te breiden?

dat is precies zoals ik het nu heb inderdaad!

[Verwijderd]

eamelink schreef op vrijdag 06 juli 2007 @ 12:54:
Dat is zo, maar er zijn natuurlijk zat situaties te bedenken waar de naam gewoon nog niet bekend is tijdens het devven.

Er is vast een situatie te verzinnen maar dat zegt helemaal niets over de vraag of het nu serig is of niet. Een handjevol uitzondering zijn daar echt niet doorslaggevend in, ze zijn niet echt relevant. Wat wel relevant is is de veiligheid van het gebruik van 'eval' methodes. Je kunt namelijk elke willekeurige methode aanroepen dus ook system calls.

Dus wanneer je gebruik gaat maken van een eval methode dan zet je feitelijk je hele systeem open (ik denk dat dit duidelijk als smerig te bestempelen is). Veel logischer is het dus om de mogelijke functies te registreren. De simpelste implementatie is een Map waarin functienamen en concrete functies staan. Je kunt dan enkel geregistreerde functies aanroepen. Geen smerige eval, wel veiligheid en vrijheid.

[Verwijderd]

MBV schreef op zaterdag 07 juli 2007 @ 10:24:
[...]

Omdat het programma van de ts er waarschijnlijk zo uit zou kunnen zien:

PHP:

function get_bezoekers ($filter)
{
  $sql = "SELECT * FROM bezoekers WHERE ";
  switch ($filter)
  {
    case 'vandaag': 
       $sql .= 'date >= VAGE_FUNCTIE_VOOR_VANDAAG';
       break;
    case 'maand': 
       $sql .= 'date >= VAGE_FUNCTIE_VOOR_MAAND';
       break;
    default:
       die('unexpected case');
  }
  $db &= database::getDB();//singleton ;)
  $db->execute($sql);
}

Dat is toch veel handiger dan 2x die query copy/pasten, en veel makkelijker uit te breiden?

True

[eamelink]

Creepy schreef op vrijdag 06 juli 2007 @ 16:40:
Met behulp van functie pointers, polymorphisme of interfaces kan je prima zaken uitbreidbaar houden zonder daar je hoeft terug te vallen op variabele functienamen en er zal ook nog wel een design pattern voor wezen. Als dat allemaal geen optie is dan zou ik pas gaan nadenken over variabele functienamen.

Absoluut, maar polymorphisme en interfaces had ik niet veel aan in mijn geval, en een variabele functienaam is de PHP variant van een functie pointer

Gonadan schreef op zaterdag 07 juli 2007 @ 10:33:
Om eerlijk te zijn lijkt mij dat eerder een ontwerp wat dus niet makkelijk uit te breiden was en is het met variabele functienamen opgelost. In mijn ogen niet echt netjes. Zelf zou ik bijvoorbeeld liever de tags met hun html equivalent declareren in een array. En dat waarschijnlijk nog in een include. Dan is het makkelijk aan te passen en oneindig uit te breiden.

Dat beperkt de mogelijkheden enorm. Dan kan je alleen maar heel simpel ubb naar html mappen. Met mijn manier kan een ubb tag _alles_ dat php zelf kan. Als ik een [googleresults=3]zoekterm[/] tag wil, kan ik een tag maken die een query uitvoert op google en de eerste drie resultaten weergeeft. Zie dat maar eens voor elkaar te krijgen met een array om ubb naar html te mappen

Verwijderd schreef op zaterdag 07 juli 2007 @ 10:43:
Er is vast een situatie te verzinnen maar dat zegt helemaal niets over de vraag of het nu serig is of niet. Een handjevol uitzondering zijn daar echt niet doorslaggevend in, ze zijn niet echt relevant. Wat wel relevant is is de veiligheid van het gebruik van 'eval' methodes. Je kunt namelijk elke willekeurige methode aanroepen dus ook system calls.

Eigenlijk zeg je dus dat variabele functienamen smerig zijn als je niet de juiste condities garandeert? Dat klopt inderdaad Maar in de praktijk zorg je natuurlijk dat je die condities wél creeert

Dus wanneer je gebruik gaat maken van een eval methode dan zet je feitelijk je hele systeem open (ik denk dat dit duidelijk als smerig te bestempelen is). Veel logischer is het dus om de mogelijke functies te registreren. De simpelste implementatie is een Map waarin functienamen en concrete functies staan. Je kunt dan enkel geregistreerde functies aanroepen. Geen smerige eval, wel veiligheid en vrijheid.
[/quote]
Dat is natuurlijk vergelijkbaar met mijn voorbeeld waar alle ubb functies beginnen met ubb_ of - niet genoemd - zoals het in mijn framework werkt; dat alle actions beginnen met show. Dat voorkomt dat zomaar elke method uitgevoerd kan worden.:)