Re: RFC: Add `final class Vector` to PHP

Hey Marco Pivetta, > Would it perhaps make sense to drag in php-ds, which has matured quite a bit over the years? > I'm referring > to: https://www.php.net/manual/en/class.ds-sequence.php > > Is what you are suggesting with Vector different from it? > > Note: For some reason, I can't quote your post and then reply, so it will be a top-post > 🤷‍♀️ This was outlined in the section https://wiki.php.net/rfc/vector#why_not_use_php-ds_instead before I sent out the announcement. To expand on that, This has been asked about multiple times in threads on unrelated proposals (https://externals.io/message/112639#112641 and https://externals.io/message/93301#93301 years ago) throughout the years, but the maintainer of php-ds had a long term goal of developing the separately from php's release cycle (and was still focusing on the PECL when I'd asked on the GitHub issue in the link almost a year ago). - There have been no proposals from the maintainer to do that so far, that was what the maintainer mentioned as a long term plan. - I personally doubt having it developed separately from php's release cycle would be accepted by voters (e.g. if unpopular decisions couldn't be voted against), or how backwards compatibility would be handled in that model, and had other concerns. (e.g. API debates such as https://externals.io/message/93301#93301) - With php-ds itself getting merged anytime soon seeming unlikely to me, I decided to start independently working on efficient data structure implementations. I don't see dragging it in (against the maintainer's wishes) as a viable option for many, many, many reasons. But having efficient datastructures in PHP's core is still useful. - While PECL development outside of php has its benefits for development and ability to make new features available in older php releases, it's less likely that application and library authors will start making use of those data structures because many users won't have any given PECL already installed. (though php-ds also publishes a polyfill, it would not have the cpu and memory savings, and add its own overhead) - Additionally, users (and organizations using PHP) can often make stronger assumptions on backwards compatibility and long-term availability of functionality that is merged into PHP's core. So the choice of feature set, some names, signatures, and internal implementation details are different, because this is reimplementing a common datastructure found in different forms in many languages. It's definitely a mature project, but I personally feel like reimplementing this (without referring to the php-ds source code and without copying the entire api as-is) is the best choice to add efficient data structures to core while respecting the maintainer's work on the php-ds project and their wish to maintain control over the php-ds project. As a result, I've been working on implementing data structures such as Vector based on php-src's data structure implementations (mostly SplFixedArray and ArraayObject) instead (and based on my past PECL/RFC experience, e.g. with runkit7/igbinary) Regards, Tyson