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

Hi Mike Schinkel, > >> Given there seems to be a lot of concern about the approach the RFC proposes would it > >> not address the concerns about memory usage and performance if several methods were added to > >> SplFixedArray instead (as well as functions like indexOf(), contains(), map(), filter(), > >> JSONSerialize(), etc., or similar): > >> > >> =============== > >> > >> setCapacity(int) — Sets the Capacity, i.e. the maximum Size before resize > >> getCapacity():int — Gets the current Capacity. > >> > >> setGrowthFactor(float) — Sets the Growth Factor for push(). Defaults to 2 > >> getGrowthFactor():float — Gets the current Growth Factor > >> > >> pop([shrink]):mixed — Returns [Size] then subtracts 1 from Size. If (bool)shrink > >> passed then call shrink(). > >> push(mixed) — Sets [Size]=mixed, then Size++, unless Size=Capacity then setSize(n) > >> where n=round(Size*GrowthFactor,0) before Size++. > >> > >> grow([new_capacity]) — Increases memory allocated. Sets Capacity to > >> Size*GrowthFactor or new_capacity. > >> shrink([new_capacity]) — Reduces memory allocated. Sets Capacity to current Size or > >> new_capacity. > >> > >> =============== > >> > >> If you had these methods then I think you would get the memory and performance > >> improvements you want, and if you really want a final Vector class for your own uses you could roll > >> your own using inheritance or containment.. > > > > I asked 8 months ago about > > push/pop in SplFixedArray. The few > > responses were unanimously opposed to SplFixedArray being repurposed like a vector, the setSize > > functionality was treated more like an escape hatch and it was conceptually for fixed-size data. > > Hmm. I must have missed that thread as I was definitely following the list at that time. > > But I found the thread, which only had three (3) comments from others: > > https://externals.io/message/112639 > > From Levi Morrison it seems his objection was to adding push() > and pop() to a class including the name "Fixed."  Levi > suggested soft-deprecating SplStack because it was implemented as a > linked-list, but he proposed adding Spl\ArrayStack or similar, so it > seems he was open to iterating on the Spl classes in general (no pun > intended.) > > From Nikita is seemed that he did not object so much as comment on Levi's suggestion of > adding Spl\ArrayStack and suggested instead an > SqlDeque that would handle queue usage more efficiently that plain > PHP arrays. > > So I think those responses were promising, but that you did not followed up on them. I mean no > disrespect — we all get busy, our priorities change, and things fall off our radar — but it > feels to me like you might have more success pursing your use-cases related to the > Spl classes than via a pure Vector > class. Experience in past RFCs gave me the impression that if: 1. All of the responses are suggesting using a different approach(php-ds, arrays), 2. Other comments are negative or uninterested. 3. None of the feedback on the original idea is positive or interested in it. When feedback was like that, voting would typically have mostly "no" results. Some of the feedback such as *Deque was interesting, but not related to extending SplFixedArray. > Maybe propose an SplVector class that extends > SplFixedArray, or something similar that addresses the use-case and > with a name that people can agree on? I'd be stuck with all of the features in SplFixedArray that get introduced later and its design deisions. > BTW, here are two other somewhat-related threads: > > - https://externals.io/message/110731 > - https://externals.io/message/113141 > > > I also believe adding a configurable growth factor would be excessive for a high level > > language. > > I wavered on whether or not to propose a configurable growth factor, but ironically I did so to > head off the potential complaint from anyone who cares deeply about memory usage (isn't that > you?) that not allowing the growth factor to be configurable would mean that either the class would > use too much memory for some use-cases, or would need to reallocate more memory too frequently for > other use-cases, depending on what the default growth factor would be. > > That said, I don't see how a configurable growth factor should be problematic for PHP? For > those who don't need/care to optimize memory usage or reallocation frequency they can simply > ignore it; no harm done. But for those who do care, it would give them the ability to fine tune > their memory usage, which for selected use-cases could mean the difference between being able to > implement something in PHP, or not. > > Note that someone could easily argue that adding a memory-optimized data structure when we > already have a perfectly flexible data structure with PHP arrays that can be used for the same > algorithms is "excessive for a high-level language."  But then I don't think you > would make that argument, so why make it for a configurable growth factor? #honestquestion The growth factor is even lower level than shrinkToFit/reserve, and requires extra memory to store the float, extra cpu time to do floating point multiplication rather than doubling, and additional API methods for something that 99% of applications wouldn't use. I consider it more suitable for a low level language. And if we discover a different resizing strategy is better, it prevents us from changing it. > > 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). > > And finally I think when you conveyed the intent of the author of ext-ds*ë#ø§ > ”aù¢šhª¨_, you omitted part of his full statement. When seen in full I believe his statement conveys > a different interest than the partial one implies: > > https://github.com/php-ds/ext-ds/issues/156 > > While he did say "My long-term intention has been to not merge this extension into > php-src" he immediately also said "I would like to see it become available as a default > extension at the distribution level." > > Based on his full statement I assume that an RFC that would propose adding an uncommented  > extension=ext-ds.so in the default > php.ini would have the author of ext-ds' backing. Assuming > 2/3rd of voters would agree, that seems like a really easy lift, implementation-wise? > > Adding an apparently well-respected extension to default > php.ini and mentioning in the release notes so that userland PHP > developers would become aware of it, start using it, writing blog posts about it, and asking > questions on StackOverflow about it would be a net plus. And those who use managed PHP hosts that > stick with the officially-blessed extensions would actually finally have access to it; those who use > WordPress managed hosts, for example. Do you mean "commented" (with ;extension=ext-ds) or "uncommented"? I read the response in a totally different way. See https://externals.io/message/116048#116054 for more details, I've been busy answering emails and haven't had time to collect all of the feedback and update this RFC with that, but I'd planned to. > 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. If you look at the bottom of the thread, the maintainer had closed the request and Benjamin Morel had asked about reconsidering 8 months ago https://github.com/php-ds/ext-ds/issues/156#issuecomment-752179461 Since the maintainer hadn't responded since then (and due to above points), I don't see a point in repeating the same request to reconsider when nothing has changed. (Also, they're working on a v2 major release, and there's no timeline for that that I know of. It could be several years.) I don't want to encourage comments that didn't introduce any new or unconvincing arguments (e.g. not "I want this too") on their GitHub issues pages, which is why I hadn't linked the original GitHub issue, but yes, I can quote more of the response in that section. > Of course including it would not preclude adding new data structures into core in the future. > Heck, with more people using ext-ds there will likely be greater > awareness of such functionality and better recognition of its short-comings — assuming it has them > — and thus facilitate more interest in adding better data structures to PHP core later on. > > Also, I noticed in that 5-year old link you referenced that a few vocal members on the list > bikeshedded over some of the finer details of the ext-ds API.  If > an RFC to include ext-ds in php.ini > were to be submitted I would implore those people and others to consider that this is the inclusion > of an extension to php.ini and not a feature in PHP core, and thus > to please not let the perfect be the enemy of the good. > > ===== > > Given the above, I think you have one of two (2) potential directions to pursue (or both) that > each might bring more fruit than the RFC discussed on this thread: > > 1. Propose an additional Spl class. This is an additional class **in** Spl. Nothing is forcing all future functionality to use Spl as a prefix, ArrayObject already exists without a prefix (Iterators also exist without an Spl prefix), and as an end user, my personal preference is short names. And functionality has moved from Spl to core before (e.g. Iterator originated in Spl and moved to core) Those data structures were all added in php 5.3. PHP has had significantly stricter discussion and voting threshold requirements for the introduction of new functionality since then, performance and memory usage improvements, etc., and using a different naming pattern for new data structures that fill in missing functionality or add better functionality is something I feel is worth proposing to distinguish new additions from the old data structures. I checked out and grepped the top 400 composer packages - none of them seemed to be declaring a class Vector/trait/interface. > 2. Propose addition of ext-ds to the default php.ini I feel like it would be inappropriate for someone who isn't a maintainer of ext-ds to propose that, especially when I'm unclear about the exact form of their long-term goals, project plans, or when ext-ds 2.0 would be out. Thanks, Tyson