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` > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
