Hi Pierre, > That's nice, and I like it, but like many people I will argue about the > API itself. > > One thing is that there's many methods in there that would totally fit > generic collection common interfaces, and in that regard, I'd be very > sad that it would be merged as is.
It isn't an interface, but my previous attempts at introducing common functionality for working with iterables have failed, e.g. with preferring userland reasons or being too small in scope among the reasons. https://wiki.php.net/rfc/any_all_on_iterable#straw_poll Until there's a Set type or a Map type, adding generic functionality such as contains() to all spl data structures is harder. I haven't seen any recent additions of utility methods to existing spl datastructures in years other than when filling an urgent need, (e.g. SplHeap->isCorrupted()) and have been pessimistic about that succeeding, but may be mistaken. > I think it's taking the problem backwards, I would personally prefer that: > > - This RFC introduces the vector into a new Collection namespace, or > any other collection/iterable/enumerable related namespace, that'd > probably become the birth of a later to be standard collection API. > > - Start thinking about a common API even if it's for one or two > methods, and propose something that later would give the impulsion for > adding new collection types and extending this in order to be become > something that looks like a really coherent collection API. > > If this goes in without regarding the greater plan, it will induce > inconsistencies in the future, when people will try to make something > greater. I'd love having something like DS and nikic/iter fused > altogether into PHP core, as a whole, in a consistent, performant, with > a nice and comprehensive API (and that doesn't require to install > userland dependencies). Aside: https://github.com/TysonAndre/pecl-teds#iterable-functions starts doing that, but evaluating eagerly instead of using generators. I still don't think there's enough functionality yet to re-propose that. > I know this vector proposal is not about that, but nevertheless, in my > opinion, it must start preparing the terrain for this, or all other RFC > in the future will only create new isolated data structures and make the > SPL even more inconsistent. It's possible, but I don't know what others think. 1. https://www.php.net/manual/en/class.ds-collection.php actually seems fairly universal, but out of scope, and I don't know if people would json encode a SplMaxHeap. Right now that isn't implemented and the value is always `{}` 2. `add($value)/remove($value)/contains[Value]($value)` is limited to some structures - Only containsValue() would apply to ArrayObject/SplObjectStorage. The others wouldn't work since you'd need to know the keys as well. Also, - Union type/intersection type support exists, so allowing any generic collection interface is less urgent. - equals() may work, though infinite recursion (or the way it is or isn't detected) in circular data structures is a potential objection, especially with lack of stack overflow detection - php just crashes/segfaults without a useful method when it runs out of stack space. For the ones that are universal, Countable/ArrayAccess/IteratorAggregate/Traversable already exist. Also, as you said, this RFC is not about that. Requiring that anyone systematically overhaul existing data structures before adding any new data structures seems like it would significantly delay or discourage any future additions of data structures. In the immediate future, an RFC only doing that would not have much short-term benefit to users - it would also have short-term drawbacks for what I consider not enough benefit, if adopting that interface made libraries drop support for older php versions. Thanks, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
