Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116070
Message-ID: <d44557e8-175b-8209-3062-b34e822489f7@processus.org>
Date: Fri, 17 Sep 2021 15:15:11 +0200
MIME-Version: 1.0
Content-Language: en-US
To: tyson andre <tysonandre775@hotmail.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <DM6PR07MB6618D41DE7680BE2BE8086DAF9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <ec2d0a55-24a6-d13d-f106-b29cbafd86bf@processus.org>
 <DM6PR07MB66189694A4E692C8422F56EEF9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB66189694A4E692C8422F56EEF9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP
From: pierre-php@processus.org (Pierre)

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