Hi Tyson, Thanks for the reply.
> On Sep 18, 2021, at 7:26 PM, tyson andre <tysonandre...@hotmail.com> wrote: > > 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. 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? 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 > 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. 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. 2. Propose addition of ext-ds to the default php.ini -Mike > > I also believe adding a configurable growth factor would be excessive for a > high level language. > > Thanks, > Tyson > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
