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

> On Sep 19, 2021, at 8:55 AM, tyson andre <tysonandre775@hotmail.com> wrote: > > Hi Mike Schinkel, >> >> 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. Understood, but for clarity I was implying that wanting to change SplFixedArray was an "XY problem" and that maybe the way to address your actually use-cases was to pursue other approaches that people were suggesting, which _is_ what you did yesterday. :-) >> 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. You wouldn't be stuck with all the feature of SplFixedArray if you did "something similar." (I make this point only as it seems you have dismiss one aspect of my suggestion while not acknowledging the alternatives I present. Twice now, at least.) >> 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. I respect your points here, but disagree. > And if we discover a different resizing strategy is better, it prevents us from changing it. This is not true. We could easily no-op the GrowthFactor method and it would not break anything in 99.9...% percent of use-cases. The relevant question here should be, what is the likelihood of us discovering a better resizing strategy that would not benefit at all from a growth factor? Is there evidence of one anywhere else? I know that Go — designed to be performant to the extent it does not add complexity — uses a growth factor. >> And finally I think when you conveyed the intent of the author of >> ext-ds 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"? Definitely uncommented. Otherwise it would not be available in a default install and thus not available at for most web hosts. > I read the response in a totally different way. Which is why it is helpful to have multiple people interpret online communication when the communication is from someone not currently participating in the discussion. :-) > 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 ’µæQ?-Äë¹ > \cBhttps://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 Yes, I had read that before sending my reply. > 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.) Maybe I am missing something, but since he published it as open-source and said he wants it to be included in distribution I would not think it would requires the maintainer to have to be the one to do the work to get it into PHP. I think it would be perfectly acceptable for supporters of his library to do the work to get into PHP. Why would that not be an option? And rather than make a wrong assumption we could minimally you could submit an issue on his repo asking the specific question of whether or not he would support adding ext-ds to php.ini. Then we would know explicitly. (#fwiw I don't plan to do that myself because I don't currently have a strong need for these data structures so am not one to write then champion such an RFC.) >> 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. Yes, all true — and I dislike Spl too — but my point was you'd probably more likely see success quicker if you proposed in Spl. But if that's not something you would do, then it a moot point. >> 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. I already commented on that above so won't repeat it here. -Mike