hi,
hi,
Ich kann mir da schon Fälle vorstellen, wo das ganz nützlich sein kann, und zwar immer dann, wenn mit callbacks gearbeitet wird, die aber gleichzeitig Daten aus dem umgebenden Scope benötigen.
Vergleiche z.b. das Beispiel von dieser Seite zum Sortieren eines Arrays nach einem beliebigen Attribut:
<?php
function sortBy(&$items, $key){
if (is_array($items)){
return usort($items, function($a, $b) use ($key){
return strCmp($a[$key], $b[$key]);
});
}
return false;
}
> >
> > Die Vergleichsfunktion (function($a, $b)) benötigt Daten aus dem umgebenden Scope ($key).
> >
> > Natürlich kann man das theoretisch auch anders bauen (man könnte z.b. eine eigene Klasse "Sortable" implementieren, der man dann die benötigten Daten bei der Erzeugung mitgibt o.ä.), aber man spart sich Schreibarbeit, weil man dank Lambda/Closure-Ausdrücken den Callback direkt in den Funktionsaufruf von usort schreiben kann. Macht IMO den Code auch lesbarer, denn man sieht jetzt sofort, dass der Callback zum usort-Aufruf gehört.
>
> Jo ;-). Klingt plausibel.
Ich finde noch: "Reduce your closure usage for factories
It’s common usage in ZF 2 to handle dependencies through the use of closures as factories in the getServiceConfig of your Module.php class. Instead, you’d better use explicit class factories, and set define the factories in the module.config.php file (in the service\_manager key). This is slightly more efficient (because closures are instantiated, it’s faster to create a string than a closure), allow you to cache config file (closure are not cacheable), and remove the unreadeable Module.php with tons of closures."
<http://www.michaelgallego.fr/blog/2013/01/21/some-tips-to-write-better-zend-framework-2-modules/>
mfg
tami