Open llaville opened 5 months ago
Hi @llaville, I'm not completely against it, but I've already considered to implement Countable on the finders and chose not to do so for two reasons:
count
call. On the contrary iterator_count
signals that an iterator is involved and this can possibly have side-effects.Anyway, if there's a particularly useful (non-trivial) use case, it's ok for me to implement it.
@alekitto could you explain "Iterating such finders can potentially cause side-effects" ? (I don't see what context will lead to a side-effect)
PS: Unless you have in mind note at https://symfony.com/doc/current/components/finder.html#transforming-results-into-arrays (about iterator_to_array
) but it's not about iterator_count
iterator_count
(as well as iterator_to_array
) iterates the iterator to its end. In this case all the finders (except the php documentor one) include the class files and/or trigger the php autoloading mechanism which can potentially produce side-effects or raise an error.
Just including a file (and registering its classes and functions) is a side-effect IMHO. The only way to not produce any side-effect is to use a non-including finder (phpDocumentor for example which unfortunately does not support attributes, but I'm also working on a finder based on php-parser) that can read the php files without adding them to the runtime.
It's interresting, because I have the same idea, and currently working on such solution. Find classes and also other symbols based on nikic/php-parser.
Hello @alekitto
With my first report #13, I've found that
ComposerFinder
(but its always true to all other) is not yet able to count values of classes found (like Symfony Finder did it).Compares both syntaxes
This one works with current version 0.4.0
But not yet this one
I suggest to fix at least the
ComposerFinder
code like thisAnd think about other finders, or have a common fix !
WDYT ?