Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116117
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <DM6PR07MB66186E811A4153A3B83F068BF9DF9@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Tue, 21 Sep 2021 15:21:12 -0400
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <4ACF2BD0-EB26-4101-BF69-2E35373F2994@newclarity.net>
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>
To: tyson andre <tysonandre775@hotmail.com>
Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP
From: mike@newclarity.net (Mike Schinkel)

> On Sep 19, 2021, at 8:55 AM, tyson andre <tysonandre775@hotmail.com> =
wrote:
>=20
> Hi Mike Schinkel,
>>=20
>> Hmm. I must have missed that thread as I was definitely following the =
list at that time.=20
>>=20
>> But I found the thread, which only had three (3) comments from =
others:
>>=20
>> https://externals.io/message/112639
>>=20
>> =46rom 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.)=20
>>=20
>> =46rom 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.
>>=20
>> So I think those responses were promising, but that you did not =
followed up on them. I mean no disrespect =E2=80=94 we all get busy, our =
priorities change, and things fall off our radar =E2=80=94 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.
>=20
> Experience in past RFCs gave me the impression that if:
>=20
> 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.
>=20
> 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?
>=20
> 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."=20

(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 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.
>>=20
>> 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.
>>=20
>> 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
>=20
> 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.=20

We could easily no-op the GrowthFactor method and it would not break =
anything in 99.9...% percent of use-cases.

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 =E2=80=94 designed to be performant to the extent it does not =
add complexity =E2=80=94 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:
>>=20
>> https://github.com/php-ds/ext-ds/issues/156
>>=20
>> 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."=20
>>=20
>> Based on his full statement I assume that an RFC that would propose =
adding an uncommented  `extension=3Dext-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?
>>=20
>> 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.=20
>=20
> Do you mean "commented" (with `;extension=3Dext-ds`) or "uncommented"?

Definitely uncommented. =20

Otherwise it would not be available in a default install and thus not =
available at for most web hosts.

> 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. :-)

> 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.
>=20
>> 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=20
>  (e.g. if unpopular decisions couldn't be voted against), or how =
backwards compatibility would be handled in that model, and had other =
concerns.**=20
>  (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.
>=20
> If you look at the bottom of the thread, the maintainer had closed the =
request=20
> 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.

> 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. =20

Why would that not be an option?

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.=20

(#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.)

>> 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 =E2=80=94 assuming it has them =E2=80=94 =
and thus facilitate more interest in adding better data structures to =
PHP core later on.
>>=20
>> 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.
>>=20
>> =3D=3D=3D=3D=3D
>>=20
>> 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:
>>=20
>> 1. Propose an additional Spl class.
>=20
> 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)
>=20
> 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 =E2=80=94 and I dislike Spl too =E2=80=94 but my point was =
you'd probably more likely see success quicker if you proposed in Spl. =20=


But if that's not something you would do, then it a moot point.

>> 2. Propose addition of ext-ds to the default php.ini
>=20
> 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. =20

-Mike=