Hey, Le dim. 15 mars 2015 à 01:54, Niklas Keller <m...@kelunik.com> a écrit :
> Morning, > > I'd like to announce that I'll open the vote for the in operator later > that day. > You can find the RFC here: https://wiki.php.net/rfc/in_operator > > There was a small change: If the haystack is a string, integers are no > longer allowed as needle. This change was necessary so it's > consistently strict for both, array and string haystacks. > > Regards, Niklas > If there is one thing that can be improved in a related area: create a true "Set" datatype. You just don't imagine how often I encountered bottlenecks in PHP application where in_array() was used (thousands times per request over not so small arrays). Sometimes it can be improved by storing the value in the key part (using an array to emulate a hash thanks to the internal implementation of arrays), using SplObjectStorage in case of objects or even a bloom filter implementation [1]. Visit [2] for some inspirations. As you see , there is room for improvement to make things easier, but that wouldn't be by simply be achieved by adding an "in" keyword. Everytime I see an in_array(), I also cry, but not because of the syntax, rather because I know how it operates (think: "full table scan" if you were doing a SELECT query without proper indexes). This simply cannot be improved in a proper way without a true "Set" implementation. [1] http://pecl.php.net/package/bloomy [2] http://technosophos.com/2009/05/29/set-objects-php-arrays-vs-splobjectstorage.html Cheers, Patrick
