Hey,
Perl Critic (habe mich heute damit befasst) rät von dieser unless Schreibweise ab.
okay gut, geschmackssache, aber punkt für dich, weil ich damit neunmalklug rumgewedelt habe ;)
Profifrage:
Was liefert -r $file in einem beliebigen Kotext ohne auf -e $file zu prüfen?
Warum kann ich bei -e $file auch -r $file voraussetzen?
warn -r 'gibtsnett';
warn -e 'gibtsnett';
warn -e __FILE__;
warn -r __FILE__;
Und lässt den Anwender eines CMS im Regen stehen...
ah verstehe.
Allerdings hat es etwas für sich, den require Test über den absoluten Pfad auszuführen, und -e und -r erst in der or do{ } zu praktizieren, um die richtige Errormessage zurückzugeben.
ja würde ich auch so machen.
# auch hier ::p ist ungelücklich kurz und nichtssagend gewählt
my $method = $plugin . '::p';Es spielt keine Rolle. wie ich das Ding benenne. Dokumentieren muss ich die Perl-Plugin API und die EHF-Code-Plugin API ja sowieso.
wartbarkeit und verständlichkeit. sobald sich etwas ändert, lügen meistens die anbeistehenden kommentare und auch die dokumentation. aber auch das ist geschmackssache.
my @param = split ($parameterSeparatorPattern, ($textToParse =~ $parameterPattern)[0]);
Das solltest du der Ordnung halber viel früher ausführen.
der ordnung halber vielleicht. ich persönlich würde es dort ausführen, weil wenn ein plugin nicht vorhanden ist, es umsonst ausgeführt wird. okay, man kann drüber streiten ob das der regelfall ist ;) allerdings ist der zusammenhalt zwischen $meth und @param sehr hoch, und da es für nichts anderes verwendet wird, habe ich es möglichst nahe an den $meth->(@params) aufruf platziert.
hth