Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116096
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] RFC: Add `final class Vector` to PHP
Thread-Index: AQHXq2Dr5ROExEhu802SAlX6zd1M+6upRoIAgAEp0s2AAEr8gIAAjOUe
Date: Sun, 19 Sep 2021 12:55:09 +0000
Message-ID:
 <DM6PR07MB66186E811A4153A3B83F068BF9DF9@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <DM6PR07MB6618D41DE7680BE2BE8086DAF9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <BC23FD6B-DE7C-49F2-B735-2FEC8572B147@newclarity.net>
 <DM6PR07MB6618581DE5810D10511104FFF9DE9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <8D04483B-8603-4C07-AB7A-D664C93F2BAB@newclarity.net>
In-Reply-To: <8D04483B-8603-4C07-AB7A-D664C93F2BAB@newclarity.net>
Accept-Language: en-CA, en-US
Content-Language: en-CA
suggested_attachment_session_id: 398a0e4e-6c13-ad65-6cba-1368b0f6b24e
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn:
 [m8vIOui+gA55v1bY/TvdkI+InnKdhoWkIk01bfE5wOIK8lcd8mdXTgRTb1Jeccm9C1qusyP0L3Q=]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d8adb2d2-1f0b-4401-f944-08d97b6cb673
x-ms-traffictypediagnostic: DM6PR07MB7866:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 cndql5v2+GAqgyHIXD35hnLZBaKEFrkrj5xg8zUdaJHmjayHrC1o8WN3+4orneprhCbjoNuC3cqwDehd6XMfMKSBUvnIUmZ8FlTEtT4Dc6AFDL5ELnH/LP5OM35zDmriRqF66rDBwk0tKBgkV2xkiMria5Yz9SsJ9ZDO1RU9ZWKEfHLtU5Zouid1ohdrBfFpGU6uX2AWXliUnnn+SpGGuVvoY/r5bJ/P4T5EYF05HjLEzDr8JfEnN2Gs78y6SNfGF/9mGOwVBv3CGMoidWxbIflJ9LenbxJIF8zWICAfZtKqmFWLbzfahtNz5pWYlcR4diXSM+i9m6TWdyEJx+E8Zf+sFNNeq/JvhWtMiEnE/1tbdIWL/hY+o08WdPWh92BWGRBJ15vMWt7I1OHj6rfvRw8h4MojAxp1Kv2NVHLS2hWaJUTFEWxNL+h4NR6AoGb47LhvaGM2lZlJrbMOSdrp+QHclSkJCrPVhL3Vr/Jueb8=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 4DH64e3BcQKHyiGRcpGc1IcwDcxUgWqbdFAHjsejzKOr2y7F/RqhhnPZWmG2kmf/Xj+NAEO/dRefUH1PslrxDAYjXucHOTUZQd60P+432oSsVBl2KD+SMsUZy5ZQaqlbIoOouB1G6jlOwW2W8Bl81d7Zx2njR0yPg9XvzK9RMMbn0LBrgX01MOjgBvsNm09BZ9+uOpLuohNb1t05JvgI7w==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-35401.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR07MB6618.namprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: d8adb2d2-1f0b-4401-f944-08d97b6cb673
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2021 12:55:09.6394
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR07MB7866
Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP
From: tysonandre775@hotmail.com (tyson andre)

Hi Mike Schinkel,=0A=
 =0A=
> >> Given there seems to be a lot of concern about the approach the RFC pr=
oposes would it not address the concerns about memory usage and performance=
 if several methods were added to SplFixedArray instead (as well as functio=
ns like indexOf(), contains(), map(), filter(), JSONSerialize(), etc., or s=
imilar):=0A=
> >> =0A=
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
> >> =0A=
> >> setCapacity(int) =97 Sets the Capacity, i.e. the maximum Size before r=
esize=0A=
> >> getCapacity():int =97 Gets the current Capacity.=0A=
> >> =0A=
> >> setGrowthFactor(float) =97 Sets the Growth Factor for push(). Defaults=
 to 2=0A=
> >> getGrowthFactor():float =97 Gets the current Growth Factor=0A=
> >> =0A=
> >> pop([shrink]):mixed =97 Returns [Size] then subtracts 1 from Size. If =
(bool)shrink passed then call shrink().=0A=
> >> push(mixed) =97 Sets [Size]=3Dmixed, then Size++, unless Size=3DCapaci=
ty then setSize(n) where n=3Dround(Size*GrowthFactor,0) before Size++.=0A=
> >> =0A=
> >> grow([new_capacity]) =97 Increases memory allocated. Sets Capacity to =
Size*GrowthFactor or new_capacity.=0A=
> >> shrink([new_capacity]) =97 Reduces memory allocated. Sets Capacity to =
current Size or new_capacity.=0A=
> >> =0A=
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
> >> =0A=
> >> If you had these methods then I think you would get the memory and per=
formance 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=
.=0A=
> > =0A=
> > I asked 8 months ago about `push`/`pop` in SplFixedArray. The few respo=
nses were unanimously opposed to SplFixedArray being repurposed like a vect=
or, the setSize functionality was treated more like an escape hatch and it =
was conceptually for fixed-size data.=0A=
> =0A=
> Hmm. I must have missed that thread as I was definitely following the lis=
t at that time. =0A=
> =0A=
> But I found the thread, which only had three (3) comments from others:=0A=
> =0A=
> https://externals.io/message/112639=0A=
> =0A=
> From Levi Morrison it seems his objection was to adding `push()` and `pop=
()` to a class including the name "Fixed."=A0 Levi suggested soft-deprecati=
ng `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.) =0A=
> =0A=
> 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.=0A=
> =0A=
> So I think those responses were promising, but that you did not followed =
up on them. I mean no disrespect =97 we all get busy, our priorities change=
, and things fall off our radar =97 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.=0A=
=0A=
Experience in past RFCs gave me the impression that if:=0A=
=0A=
1. All of the responses are suggesting using a different approach(php-ds, a=
rrays),=0A=
2. Other comments are negative or uninterested.=0A=
3. None of the feedback on the original idea is positive or interested in i=
t.=0A=
=0A=
When feedback was like that, voting would typically have mostly "no" result=
s.=0A=
=0A=
Some of the feedback such as `*Deque` was interesting, but not related to e=
xtending SplFixedArray.=0A=
=0A=
> Maybe propose an `SplVector` class that extends `SplFixedArray`, or somet=
hing similar that addresses the use-case and with a name that people can ag=
ree on?=0A=
=0A=
I'd be stuck with all of the features in `SplFixedArray` that get introduce=
d later and its design deisions.=0A=
=0A=
> BTW, here are two other somewhat-related threads:=0A=
> =0A=
> - https://externals.io/message/110731=0A=
> - https://externals.io/message/113141=0A=
> =0A=
> > I also believe adding a configurable growth factor would be excessive f=
or a high level language.=0A=
> =0A=
> 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 car=
es 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 m=
uch 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.=0A=
> =0A=
> That said, I don't see how a configurable growth factor should be problem=
atic for PHP? For those who don't need/care to optimize memory usage or rea=
llocation 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.=0A=
> =0A=
> 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-l=
evel language."=A0 But then I don't think you would make that argument, so =
why make it for a configurable growth factor? #honestquestion=0A=
=0A=
The growth factor is even lower level than shrinkToFit/reserve, and require=
s extra memory to store the float, extra cpu time to do floating point mult=
iplication rather than doubling,=0A=
and additional API methods for something that 99% of applications wouldn't =
use.=0A=
I consider it more suitable for a low level language.=0A=
And if we discover a different resizing strategy is better, it prevents us =
from changing it.=0A=
=0A=
> > This has been asked about multiple times in threads on unrelated propos=
als (https://externals.io/message/112639#112641 and https://externals.io/me=
ssage/93301#93301 years ago) throughout the years, but the maintainer of ph=
p-ds had a long term goal of developing the separately from php's release c=
ycle (and was still focusing on the PECL when I'd asked on the GitHub issue=
 in the link almost a year ago).=0A=
> =0A=
> 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 s=
tatement conveys a different interest than the partial one implies:=0A=
> =0A=
> https://github.com/php-ds/ext-ds/issues/156=0A=
> =0A=
> While he did say "My long-term intention has been to not merge this exten=
sion into php-src" he immediately also said "I would like to see it become =
available as a default extension at the distribution level." =0A=
> =0A=
> Based on his full statement I assume that an RFC that would propose addin=
g an uncommented=A0 `extension=3Dext-ds.so` in the default `php.ini` would =
have the author of ext-ds' backing. Assuming 2/3rd of voters would agree, t=
hat seems like a really easy lift, implementation-wise?=0A=
>=0A=
> Adding an apparently well-respected extension to default `php.ini` and me=
ntioning in the release notes so that userland PHP developers would become =
aware of it, start using it, writing blog posts about it, and asking questi=
ons on StackOverflow about it would be a net plus. And those who use manage=
d PHP hosts that stick with the officially-blessed extensions would actuall=
y finally have access to it; those who use WordPress managed hosts, for exa=
mple. =0A=
=0A=
Do you mean "commented" (with `;extension=3Dext-ds`) or "uncommented"?=0A=
=0A=
I read the response in a totally different way.=0A=
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 a=
nd update this RFC with that,=0A=
but I'd planned to.=0A=
=0A=
> There have been no proposals from the maintainer to do that so far,=0A=
  that was what the maintainer mentioned as a long term plan.=0A=
> **I personally doubt having it developed separately from php's release cy=
cle would be accepted by voters =0A=
  (e.g. if unpopular decisions couldn't be voted against), or how backwards=
 compatibility would be handled in that model, and had other concerns.** =
=0A=
  (e.g. API debates such as https://externals.io/message/93301#93301)=0A=
> With php-ds itself getting merged anytime soon seeming unlikely to me,=0A=
  I decided to start independently working on efficient data structure impl=
ementations.=0A=
=0A=
If you look at the bottom of the thread, the maintainer had closed the requ=
est =0A=
and Benjamin Morel had asked about reconsidering 8 months ago https://githu=
b.com/php-ds/ext-ds/issues/156#issuecomment-752179461=0A=
=0A=
Since the maintainer hadn't responded since then (and due to above points),=
=0A=
I don't see a point in repeating the same request to reconsider when nothin=
g has changed.=0A=
(Also, they're working on a v2 major release, and there's no timeline for t=
hat that I know of. It could be several years.)=0A=
=0A=
I don't want to encourage comments that didn't introduce any new or unconvi=
ncing arguments (e.g. not "I want this too") on their GitHub issues pages,=
=0A=
which is why I hadn't linked the original GitHub issue, but yes, I can quot=
e more of the response in that section.=0A=
 =0A=
> 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 likel=
y be greater awareness of such functionality and better recognition of its =
short-comings =97 assuming it has them =97 and thus facilitate more interes=
t in adding better data structures to PHP core later on.=0A=
> =0A=
> Also, I noticed in that 5-year old link you referenced that a few vocal m=
embers on the list bikeshedded over some of the finer details of the `ext-d=
s` API.=A0 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 inclus=
ion 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.=0A=
> =0A=
> =3D=3D=3D=3D=3D=0A=
> =0A=
> 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:=0A=
> =0A=
> 1. Propose an additional Spl class.=0A=
=0A=
This is an additional class **in** Spl. Nothing is forcing all future funct=
ionality to use Spl as a prefix,=0A=
`ArrayObject` already exists without a prefix (Iterators also exist without=
 an `Spl` prefix),=0A=
and as an end user, my personal preference is short names.=0A=
And functionality has moved from Spl to core before (e.g. `Iterator` origin=
ated in Spl and moved to core)=0A=
=0A=
Those data structures were all added in php 5.3.=0A=
PHP has had significantly stricter discussion and voting threshold requirem=
ents for the introduction of new functionality since then,=0A=
performance and memory usage improvements, etc., and using a different nami=
ng pattern for new data structures that fill in missing functionality=0A=
or add better functionality is something I feel is worth proposing to disti=
nguish new additions from the old data structures.=0A=
=0A=
I checked out and grepped the top 400 composer packages - none of them seem=
ed to be declaring a `class Vector`/trait/interface.=0A=
=0A=
> 2. Propose addition of ext-ds to the default php.ini=0A=
=0A=
I feel like it would be inappropriate for someone who isn't a maintainer of=
 ext-ds to propose that,=0A=
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.=0A=
=0A=
Thanks,=0A=
Tyson=0A=