Hi Mike Shinkel, > >> 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
I said that **in response to you suggesting adding functionality to `SplFixedArray`** as the reason why I am not adding functionality to `SplFixedArray`. Those responses were promising for functionality that is not about `SplFixedArray`. The `Vector` is a name choice. `SplArrayStack` and a `Vector` would have very similar performance characteristics and probably identical internal representations. However, a more expansive standard library such as `contains`, `map`, `filter`, `reduce`, etc. makes more sense on a List/Vector than a `Stack` if you're solely going based on the name - when you hear `Stack`, you mostly think of pushing or popping from it. As you said also below in your followup response, I am following up on the suggestion for a `Deque`. > — 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. It's hard to know which approach (namespaces such as Collection\, SplXyz, or short names) will succeed without actually creating an RFC. I'd mentioned my personal reasons for expecting Spl not to be the best choice. Any email discussion only has comments from a handful of people with different arguments and preferences, and many times more people might vote on the final RFC > > 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'm not sure which of the multiple suggestions you brought up was you're referring to as "something similar". Your original suggestion I responded to was to modify "SplFixedArray", I assumed you were suggesting that I change my RFC to focus on SplFixedArray, I had the impression after feedback those changes to SplFixedArray would overwhelmingly fail especially due to being named "Fixed". I don't consider making it a subclass of SplFixedArray a good design decision. It's possible to invoke methods on base classes with `ReflectionMethod` so I can't make `Vector` a subclass of `SplFixedArray` with an entirely different implementation. So any memory SplFixedArray wastes (e.g. to mitigate bugs already found or found in the future) is also wasted in any subclass of SplFixedArray. - Additionally, this has the same problem as `SplDoublyLinkedList` and its subclasses. It prevents changing the internal representation of adding certain types of functionality if that wouldn't work with the base class. - Additionally, this would make deprecating and removing `SplFixedArray` significantly harder or impractical, if it ever seemed appropriate in the future due to lack of use. Additionally, I'm proposing a final class: SplFixedArray already exists and can't be converted to a final class because code already extends it. See https://wiki.php.net/rfc/deque#final_class for the reasons why I am opposed to making this final, and why others have also been opposed to making it final. > >> 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. I respectfully continue to disagree and don't see any good use cases for making the growth factor fine tunable for the general case. Even in years of using C++ or Java for various reasons, I haven't had a need to override it in those languages, and expect use cases to be less common in PHP. If use cases are discovered that do benefit from it, anyone can write an RFC to add this to `Vector` or `SplFixedArray` if it's approved, but I don't have plans on doing that myself. Exposing the capacity in this RFC seems like it's a mistake - it's useful in unit testing or bug reporting while initially implementing the extension, but I'll likely end up hiding it until others come up with a convincing use case for ordinary use. You also haven't brought up any use cases you have for a growth factor, just that they may exist under some circumstances. > 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. Doing that and nothing else would result in many users seeing `PHP Warning: PHP Startup: Unable to load dynamic library 'asgbn' (tried: (various paths)) in %s on line %d`, which is something I'd want to avoid. I'd elaborated a bit more on my concerns with an extension being always-on but not maintained by php internals in https://wiki.php.net/rfc/deque#perceived_issues_and_uncertainties_about_php > > 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. :-) At the time, I felt it would be unproductive and disrespectful of the maintainer's time to repeat the request that was already made if nothing at all had changed since the previous time I asked. It's been 8 months and I managed to create independent reimplementations of the core functionality of `Queue` and `Vector` data structures, so it's definitely worth checking if their position has changed. > > 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. Oh. So you read that but don't share my concerns about https://wiki.php.net/rfc/deque#perceived_issues_and_uncertainties_about_php-ds_distribution_plans I don't know how you'd actually get approval for `extension=ds` in the default php.ini. Furthermore, we don't control the contents of php.ini in OS distributions - there's a different default php.ini for Homebrew, deb/rpm (and so on) packages for various linux distributions, docker images, etc., maintained by multiple distinct groups of people. Third, my goal is a statically compiled functionality (i.e. always on), not a shared library that can be disabled through an ini setting. > > 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? If he permitted and requested that the supporters of his library to do that, he wouldn't have to do the work, yes. It's the problems in https://wiki.php.net/rfc/deque#perceived_issues_and_uncertainties_about_php-ds_distribution_plans that I'm concerned about. If he didn't permit or request it, it'd be a huge problem if he or significant contributors to the package objected to the inclusion of it in php. > 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.) For the reasons stated above I don't think adding it to php.ini is a working solution. > >> 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. If the majority of the community was in favor of it, I would switch to `SplQueue`. I'm starting a straw poll shortly that https://externals.io/message/116112 I didn't expect the majority of end users or internals to like the name `SplDeque` from feedback on previous RFCs especially with `SplDoublyLinkedList` already existing in with the performance and memory issues mentioned in the `Deque` RFC. As for adoption of namespaces - I didn't have any good ideas for namespaces at the time. I like the recently mentioned name `use Collections\Deque;`, but expected I'd end up with strong opposition to whatever namespace I could think up. > >> 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. I already responded and won't repeat it here Thanks, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
