Variadic Functions -- Was die Welt nicht braucht ...

  • http://phpmagazin.de/artikel/PHP-56-Splat-Async-Baem-172067
    https://wiki.php.net/rfc/variadics


    PHP
    1. function fn($reqParam, $optParam = null, ...$params) {
    2. var_dump($reqParam, $optParam, $params);
    3. }
    4. fn(1); // 1, null, []
    5. fn(1, 2); // 1, 2, []
    6. fn(1, 2, 3); // 1, 2, [3]
    7. fn(1, 2, 3, 4); // 1, 2, [3, 4]
    8. fn(1, 2, 3, 4, 5); // 1, 2, [3, 4, 5]


    Kurz: Durch den Operator "..." kann man in "variadic functions" ein Array erwarten.


    Was zur Hölle ist falsch daran ein Array dynamisch, oder von mir aus manuell, außen zu erstellen?!
    Das einzige, was mir auf Anhieb einfällt ist: Verschleierung.


    Der Progger überfliegt den Code und sieht wie in eine funciton mehrere Parameter mitgegeben werden.
    Ihm wird aber in dem Moment vorgegaukelt, dass in der funciton diese Parameter auch so zu erwarten sind.


    Für mich schreit das nur wieder nach:
    1. "ich bin cool, ich nutze variadic functions
    und bei IF-Abfragen nutze ich keine Klammern,
    aber dafür glaub ich das das Paket 16 Byte groß ist und prüfe nicht die tatsächliche Größe
    und goto ist sowieso voll gut"


    2. Bugs, weil jemand nicht aufgepasst hat, was in der function denn nun wirklich erwartet wird.

  • Ich muss ehrlich sagen, ich verstehe deine Ablehnung nicht?!
    Zwar fällt mir im Augenblick kein Szenario ein, wo diese variadics unabdingbar sind, allerdings klingt es auch nicht so dermaßen schlecht. Wenn einer Funktion mehrere optionale und variable Parameter zur Verarbeitung gegeben werden können, klingt das ja nicht unbedingt schlecht.


    Hier eine Idee für die Einsetzbarkeit, natürlich auch anders zu lösen

    PHP
    1. function validate(...$input, ...$type) {
    2. // Validierungskriterien
    3. }


    Hier könnte man in der Funktion für verschiedene Eingabeerwartungen verschiedene Validierungen definieren und diese dann per Array auswählen und auf den jeweiligen Input anwenden.


    Also klar, kann einerseits zur Schlamperei führen, kann andererseits in bestimmten Szenarien auch nützlich sein.
    Ähnlich mit PDO, welches Eingaben von vornherein maskiert um SQL Injections zu unterbinden. Manche denken sich daher, sie müssten eh nix mehr machen, macht ja PDO, aber trimmen uÄ ist trotzdem eigl. noch nötig :D

  • Die function würde so wohl nicht funktionieren.
    So wie ich es verstanden hab, kann man diesen Operator nur einmal nutzen.
    Denn alles war an "dieser Stelle und danach" reinkommt, kommt ins Array.
    Es würde also alles in $input landen.


    So soll es wohl nutzen bringen:

    PHP
    1. function myFunc($id, ...$para) {
    2. if($id == 3 and $para[0] = 'xyz'){
    3. // ...
    4. }
    5. }
    6. // call
    7. myFunc(3,'yxz','bla','undso');


    und so sehe ich es viel nützlicher an:

    PHP
    1. function myFunc($id, $para) {
    2. if($id == 3 and $para['name'] = 'xyz'){
    3. // ...
    4. }
    5. }
    6. myFunc(3, array('name' => 'yxz', 'text' => 'bla', 'ect' => 'undso') );


    ich sehe außen wie innen "mehr" und habe sogar keys.


    Jetzt stelle man sich einfach mal vor, dass die Parameter durch einen Dritten verändert werden müssen (Wartung, ect).
    Der passt nicht auf und denkt sich:

    PHP
    1. myFunc(3,/*'yxz',*/'bla','undso'); // xyz brauchn wa net mehr


    und in der func wird der egtl 2te ([1]) para als 1ster ([0]) genutzt.
    Das kann mit nem ordentlichen Array (keys!) nicht passieren :D