> On Sep 19, 2021, at 8:55 AM, tyson andre <tysonandre...@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 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
