Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116122
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] RFC: Add `final class Vector` to PHP
Thread-Index:
 AQHXq2Dr5ROExEhu802SAlX6zd1M+6upRoIAgAEp0s2AAEr8gIAAjOUegAOctgCAAHIGDw==
Date: Wed, 22 Sep 2021 03:50:12 +0000
Message-ID:
 <DM6PR07MB66180940C05FFFBEF7FB628AF9A29@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>
 <DM6PR07MB66186E811A4153A3B83F068BF9DF9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <4ACF2BD0-EB26-4101-BF69-2E35373F2994@newclarity.net>
In-Reply-To: <4ACF2BD0-EB26-4101-BF69-2E35373F2994@newclarity.net>
Accept-Language: en-CA, en-US
Content-Language: en-CA
suggested_attachment_session_id: 1403ccc3-80e9-364e-dcb5-11deeffb83ce
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn:
 [pdwNLJ2XBNusnu3K3ODLb1QtJcs0NUFUHQAGrWwTmL6lHBfKDFQ44fpCgiY/BFdH360B/iQDwIY=]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6e947951-da40-4473-b625-08d97d7c14a3
x-ms-traffictypediagnostic: DM6PR07MB5068:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 4RsZX/xhkhwVmpWwm6FYomjNoL4n9mU4OMEd0QWy0Uv20okFK5Ezi2Wwc6rB0DhpukX42YQowVGp99MOXCu49kYpTjXU2YgxqyOobuwxVppX6baaoW560WGanT90cE0vv8mFkVdsXT/vbfD+USk/7yCk6cNLYhka697gkjh0qnoxKdl0SOaJyLpg6g01/IvfaMljrqamNU8YTIMq471X/k04NZLzzjCvhOdvFn9azWCN7WuEP5mdOgu9ODR2aYXNt4uWFQuP/rEvB2ehUC4C4TMNYZdRUdKRdltCGJDCxEpn+Pg/LUlEiSH27QefYKm04I+0+WT1068OWoSMFqWO9FTpHQhWEbCAP5C+Wrqu4NaoFnw2llUYG9ex6NXCy/2rYa5i3wBwFlIrgOrMqqtz7agvs09UTkDOchA1zVEuUuZrVLP8syLIbcjzdu9SW8gPBC5klZ0CgbAcEuM+ysDDVVBamhl4DdshLZuLFKXZhGFXMpQr/+/tMRkMfxTkpYjjQ+0BbP1dDVosxGVmwRX7Pw==
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 HE9aRTUYWK/qQYiYhGguEZIqYEFNsaPdgKRdOwYHgeP1lXt9wf8uSjQZV7dchxV6XBjcpX/JrljOGJnxNSfhDGDDfA9yC+COYtXUCdRKivJDMlqwjtg+nKQTMpIKZ2LT1tvrLy4JinqhCyoz96sSPhIa/WJr+HtBgZTuvld73bvH0W1RGxuVP2yre2UdNZS4tdvy+hGwe/R8LXALVfHGDw==
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: 6e947951-da40-4473-b625-08d97d7c14a3
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2021 03:50:12.4486
 (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: DM6PR07MB5068
Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP
From: tysonandre775@hotmail.com (tyson andre)

Hi Mike Shinkel,=0A=
=0A=
> >> Hmm. I must have missed that thread as I was definitely following the =
list 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-deprec=
ating `SplStack` because it was implemented as a linked-list, but he propos=
ed 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 Lev=
i's suggestion of adding `Spl\ArrayStack` and suggested instead an `SqlDequ=
e` 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 follow=
ed up on them. I mean no disrespect =97 we all get busy, our priorities cha=
nge, and things fall off our radar=0A=
=0A=
I said that **in response to you suggesting adding functionality to `SplFix=
edArray`** as the reason why I am not adding functionality to `SplFixedArra=
y`.=0A=
Those responses were promising for functionality that is not about `SplFixe=
dArray`.=0A=
=0A=
The `Vector` is a name choice. `SplArrayStack` and a `Vector` would have ve=
ry similar performance characteristics and probably identical internal repr=
esentations.=0A=
However, a more expansive standard library such as `contains`, `map`, `filt=
er`, `reduce`, etc. makes more sense on a List/Vector=0A=
than a `Stack` if you're solely going based on the name - when you hear `St=
ack`, you mostly think of pushing or popping from it.=0A=
=0A=
As you said also below in your followup response, I am following up on the =
suggestion for a `Deque`.=0A=
=0A=
>  =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=
It's hard to know which approach (namespaces such as Collection\, SplXyz, o=
r short names) will succeed without actually creating an RFC.=0A=
I'd mentioned my personal reasons for expecting Spl not to be the best choi=
ce.=0A=
Any email discussion only has comments from a handful of people with differ=
ent arguments and preferences,=0A=
and many times more people might vote on the final RFC=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-d=
s, arrays),=0A=
> > 2. Other comments are negative or uninterested.=0A=
> > 3. None of the feedback on the original idea is positive or interested =
in it.=0A=
> > =0A=
> > When feedback was like that, voting would typically have mostly "no" re=
sults.=0A=
> =0A=
> Understood, but for clarity I was implying that wanting to change `SplFix=
edArray` was an "XY problem" and that maybe the way to address your actuall=
y use-cases was to pursue other approaches that people were suggesting, whi=
ch _is_ what you did yesterday.=A0 :-)=0A=
>=0A=
> >> Maybe propose an `SplVector` class that extends `SplFixedArray`, or so=
mething similar that addresses the use-case and with a name that people can=
 agree on?=0A=
> > =0A=
> > I'd be stuck with all of the features in `SplFixedArray` that get intro=
duced later and its design deisions.=0A=
> =0A=
> You wouldn't be stuck with all the feature of `SplFixedArray` if you did =
"something similar." =0A=
=0A=
> (I make this point only as it seems you have dismiss one aspect of my sug=
gestion while not acknowledging the alternatives I present. Twice now, at l=
east.)=0A=
=0A=
I'm not sure which of the multiple suggestions you brought up was  you're r=
eferring to as "something similar".=0A=
Your original suggestion I responded to was to modify "SplFixedArray",=0A=
I assumed you were suggesting that I change my RFC to focus on SplFixedArra=
y,=0A=
I had the impression after feedback those changes to SplFixedArray would ov=
erwhelmingly fail especially due to being named "Fixed".=0A=
=0A=
I don't consider making it a subclass of SplFixedArray a good design decisi=
on.=0A=
It's possible to invoke methods on base classes with `ReflectionMethod` so =
I can't make `Vector` a subclass of `SplFixedArray` with an entirely differ=
ent implementation.=0A=
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.=0A=
=0A=
=0A=
- Additionally, this has the same problem as `SplDoublyLinkedList` and its =
subclasses.=0A=
  It prevents changing the internal representation of adding certain types =
of functionality if that wouldn't work with the base class.=0A=
- Additionally, this would make deprecating and removing `SplFixedArray` si=
gnificantly harder or impractical,=0A=
  if it ever seemed appropriate in the future due to lack of use.=0A=
=0A=
Additionally, I'm proposing a final class: SplFixedArray already exists and=
 can't be converted to a final class because code already extends it.=0A=
See https://wiki.php.net/rfc/deque#final_class for the reasons why I am opp=
osed to making this final, and why others have also been opposed to making =
it final.=0A=
=0A=
> >> I wavered on whether or not to propose a configurable growth factor, b=
ut 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 gro=
wth factor to be configurable would mean that either the class would use to=
o much memory for some use-cases, or would need to reallocate more memory t=
oo frequently for other use-cases, depending on what the default growth fac=
tor would be.=0A=
> >> =0A=
> >> That said, I don't see how a configurable growth factor should be prob=
lematic 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 tho=
se who do care, it would give them the ability to fine tune their memory us=
age, which for selected use-cases could mean the difference between being a=
ble to implement something in PHP, or not.=0A=
> >> =0A=
> >> Note that someone could easily argue that adding a memory-optimized da=
ta 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 hig=
h-level 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 req=
uires extra memory to store the float,=0A=
> > extra cpu time to do floating point multiplication rather than doubling=
,=0A=
> > and additional API methods for something that 99% of applications would=
n't use.=0A=
> > I consider it more suitable for a low level language.=0A=
> =0A=
> I respect your points here, but disagree.=0A=
> =0A=
> > And if we discover a different resizing strategy is better, it prevents=
 us from changing it.=0A=
> =0A=
> This is not true. =0A=
> =0A=
> We could easily no-op the GrowthFactor method and it would not break anyt=
hing in 99.9...% percent of use-cases.=0A=
=0A=
I respectfully continue to disagree and don't see any good use cases for ma=
king the growth factor fine tunable for the general case.=0A=
Even in years of using C++ or Java for various reasons, I haven't had a nee=
d to override it in those languages,=0A=
and expect use cases to be less common in PHP.=0A=
=0A=
If use cases are discovered that do benefit from it, anyone can write an RF=
C to add this to `Vector` or `SplFixedArray` if it's approved, but I don't =
have plans on doing that myself.=0A=
=0A=
Exposing the capacity in this RFC seems like it's a mistake - it's useful i=
n 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 us=
e case for ordinary use.=0A=
=0A=
You also haven't brought up any use cases you have for a growth factor, jus=
t that they may exist under some circumstances.=0A=
=0A=
> The relevant question here should be, what is the likelihood of us discov=
ering a better resizing strategy that would not benefit at all from a growt=
h factor?=A0 Is there evidence of one anywhere else?=A0 I know that Go =97 =
designed to be performant to the extent it does not add complexity =97 uses=
 a growth factor.=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 hi=
s statement 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 ex=
tension into php-src" he immediately also said "I would like to see it beco=
me available as a default extension at the distribution level." =0A=
> >> =0A=
> >> Based on his full statement I assume that an RFC that would propose ad=
ding an uncommented=A0 `extension=3Dext-ds.so` in the default `php.ini` wou=
ld have the author of ext-ds' backing. Assuming 2/3rd of voters would agree=
, that seems like a really easy lift, implementation-wise?=0A=
> >> =0A=
> >> Adding an apparently well-respected extension to default `php.ini` and=
 mentioning in the release notes so that userland PHP developers would beco=
me aware of it, start using it, writing blog posts about it, and asking que=
stions on StackOverflow about it would be a net plus. And those who use man=
aged PHP hosts that stick with the officially-blessed extensions would actu=
ally finally have access to it; those who use WordPress managed hosts, for =
example. =0A=
> > =0A=
> > Do you mean "commented" (with `;extension=3Dext-ds`) or "uncommented"?=
=0A=
> =0A=
> Definitely uncommented.=A0 =0A=
> =0A=
> Otherwise it would not be available in a default install and thus not ava=
ilable at for most web hosts.=0A=
=0A=
Doing that and nothing else would result in many users seeing =0A=
`PHP Warning:  PHP Startup: Unable to load dynamic library 'asgbn' (tried: =
(various paths)) in %s on line %d`,=0A=
which is something I'd want to avoid.=0A=
=0A=
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#perce=
ived_issues_and_uncertainties_about_php=0A=
 =0A=
> > I read the response in a totally different way.=0A=
> =0A=
> Which is why it is helpful to have multiple people interpret online commu=
nication when the communication is from someone not currently participating=
 in the discussion. :-)=0A=
=0A=
At the time, I felt it would be unproductive and disrespectful of the maint=
ainer's time to repeat the request that was already made=0A=
if nothing at all had changed since the previous time I asked.=0A=
=0A=
It's been 8 months and I managed to create independent reimplementations of=
 the core functionality of `Queue` and `Vector` data structures,=0A=
so it's definitely worth checking if their position has changed.=0A=
 =0A=
> > See https://externals.io/message/116048#116054 for more details,I've be=
en busy answering emails and haven't had time to collect all of the feedbac=
k and 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=
> >=A0 that was what the maintainer mentioned as a long term plan.=0A=
> >> **I personally doubt having it developed separately from php's release=
 cycle would be accepted by voters =0A=
> >=A0 (e.g. if unpopular decisions couldn't be voted against), or how back=
wards compatibility would be handled in that model, and had other concerns.=
** =0A=
> >=A0 (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=
> >=A0 I decided to start independently working on efficient data structure=
 implementations.=0A=
> > =0A=
> > If you look at the bottom of the thread, the maintainer had closed the =
request =0A=
> > and Benjamin Morel had asked about reconsidering 8 months ago https://g=
ithub.com/php-ds/ext-ds/issues/156#issuecomment-752179461=0A=
> =0A=
> Yes, I had read that before sending my reply.=0A=
 =0A=
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_pla=
ns=0A=
=0A=
I don't know how you'd actually get approval for `extension=3Dds` in the de=
fault php.ini.=0A=
Furthermore, we don't control the contents of php.ini in OS distributions -=
 there's a different default php.ini for Homebrew, =0A=
deb/rpm (and so on) packages for various linux distributions, docker images=
, etc., maintained by multiple distinct groups of people.=0A=
=0A=
Third, my goal is a statically compiled functionality (i.e. always on), not=
 a shared library that can be disabled through an ini setting.=0A=
=0A=
> > Since the maintainer hadn't responded since then (and due to above poin=
ts),=0A=
> > I don't see a point in repeating the same request to reconsider when no=
thing has changed.=0A=
> > (Also, they're working on a v2 major release, and there's no timeline f=
or that that I know of. It could be several years.)=0A=
> =0A=
> Maybe I am missing something, but since he published it as open-source an=
d said he wants it to be included in distribution I would not think it woul=
d requires the maintainer to have to be the one to do the work to get it in=
to PHP. I think it would be perfectly acceptable for supporters of his libr=
ary to do the work to get into PHP.=A0 =0A=
> =0A=
> Why would that not be an option?=0A=
 =0A=
If he permitted and requested that the supporters of his library to do that=
, he wouldn't have to do the work, yes.=0A=
It's the problems in https://wiki.php.net/rfc/deque#perceived_issues_and_un=
certainties_about_php-ds_distribution_plans that I'm concerned about.=0A=
=0A=
If he didn't permit or request it, it'd be a huge problem if he or signific=
ant contributors to the package objected to the inclusion of it in php.=0A=
=0A=
> And rather than make a wrong assumption we could minimally you could subm=
it an issue on his repo asking the specific question of whether or not he w=
ould support adding `ext-ds` to `php.ini`. Then we would know explicitly. =
=0A=
> =0A=
> (#fwiw I don't plan to do that myself because I don't currently have a st=
rong need for these data structures so am not one to write then champion su=
ch an RFC.)=0A=
=0A=
For the reasons stated above I don't think adding it to php.ini is a workin=
g solution.=0A=
=0A=
> >> Of course including it would not preclude adding new data structures i=
nto core in the future. Heck, with more people using `ext-ds` there will li=
kely be greater awareness of such functionality and better recognition of i=
ts short-comings =97 assuming it has them =97 and thus facilitate more inte=
rest 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 voca=
l members on the list bikeshedded over some of the finer details of the `ex=
t-ds` API.=A0 If an RFC to include `ext-ds` in `php.ini` were to be submitt=
ed I would implore those people and others to consider that this is the inc=
lusion 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 f=
unctionality to use Spl as a prefix,=0A=
> > `ArrayObject` already exists without a prefix (Iterators also exist wit=
hout 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` or=
iginated 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 requ=
irements for the introduction of new functionality since then,=0A=
> > performance and memory usage improvements, etc., and using a different =
naming pattern for new data structures that fill in missing functionality=
=0A=
> > or add better functionality is something I feel is worth proposing to d=
istinguish new additions from the old data structures.=0A=
> =0A=
> Yes, all true =97 and I dislike Spl too =97 but my point was you'd probab=
ly more likely see success quicker if you proposed in Spl.=A0 =0A=
> =0A=
> But if that's not something you would do, then it a moot point.=0A=
=0A=
If the majority of the community was in favor of it, I would switch to `Spl=
Queue`. I'm starting a straw poll shortly that https://externals.io/message=
/116112=0A=
I didn't expect the majority of end users or internals to like the name `Sp=
lDeque` from feedback on previous RFCs =0A=
especially with `SplDoublyLinkedList` already existing in with the performa=
nce and memory issues mentioned in the `Deque` RFC.=0A=
=0A=
As for adoption of namespaces - I didn't have any good ideas for namespaces=
 at the time.=0A=
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.=0A=
=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 maintaine=
r of ext-ds to propose that,=0A=
> > especially when I'm unclear about the exact form of their long-term goa=
ls, project plans, or when ext-ds 2.0 would be out.=0A=
> =0A=
> I already commented on that above so won't repeat it here.=A0 =0A=
=0A=
I already responded and won't repeat it here=0A=
=0A=
Thanks,=0A=
Tyson=0A=