Le 17/09/2021 à 14:54, tyson andre a écrit :
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.
Nice to know this, I wasn't aware it even existed, I'll have a look.
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.
That's true, vector is a bit aside of what we'd expect from a full blown
collection API, it's a very basic structure in the end so it can
probably live on its own.
Also,
- Union type/intersection type support exists, so allowing any generic
collection interface is less urgent.
That's right, but I don't think that union/intersection types solve the
generic collection problem, you'd still have to match for specific class
names or interfaces if methods are not rationalised in a single API.
- 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.
Yes, they exist, but I wouldn't place IteratorAggregate as being part of
the interface, it's about implementation, but right. Anyway altogether
they form a very poor API covering a very small surface and I'd imagine
those becoming a legacy thing if a new API was introduced.
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.
I think your point is legit, and a part of me agrees with you, probably
having some data structure before thinking about rationalisation is
something that would make people move forward. Nevertheless it's always
very difficult to change things once they're here, and the whole problem.
I crave so deeply for a complete, easy to use, well documented and
standard collection API that I always jump on such RFC's to tell people
"stop using DS, stop using Doctrine Collections, stop using "[name it
here] collection", please everyone, let's design, implement and use the
single and same one, so that we will never have to support them all
(them being the 1,000 existing duplicated library in userland) in our
framework or business code.
Thanks a lot for your answer and you time, despite the fact I still
think that designing a collection first can still be done, having the
vector type/class in core is a great idea.
Regards,
--
Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
