Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116068
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] RFC: Add `final class Vector` to PHP
Thread-Index: AQHXq2Dr5ROExEhu802SAlX6zd1M+6un8gqAgAA4uM4=
Date: Fri, 17 Sep 2021 12:54:33 +0000
Message-ID:
 <DM6PR07MB66189694A4E692C8422F56EEF9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <DM6PR07MB6618D41DE7680BE2BE8086DAF9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <ec2d0a55-24a6-d13d-f106-b29cbafd86bf@processus.org>
In-Reply-To: <ec2d0a55-24a6-d13d-f106-b29cbafd86bf@processus.org>
Accept-Language: en-CA, en-US
Content-Language: en-CA
suggested_attachment_session_id: 8eec8c5e-2077-3fef-c86c-86ff9237a818
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [hw8gpL+5yBINZFoe4E4CKa8Ylf/dfBoTYw3GOTbbvZBuAhx01O1cmeqaxSs8RHRf]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ef50f147-c81a-4fef-c7cd-08d979da4bca
x-ms-traffictypediagnostic: DM6PR07MB7913:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 HTNKLd6UbeQpwLT2UkUGTHc5O047P0UEty8bpq+lSgI8sE/RgYC3slrt5XyFh1nVhUpiLrLQqAd8QZeZhyx6BBcovH5lmqt+yaANOeHUDGaqkDg1WCqsn9EvIKykH1XES85VLK12b8FDF4V+yP5KumlqhvOOMnw9EHm0ADp8Amb0XOJr9cfK5gYkkl6IsTBy0Wqny+o8mLSBFGsxDkBXn9dQD5GIuA5ujysHyVpqpQN6YcBORNRsgX3ct5tq9QnS9KZHr6dAC0rNLnf/2EIxML7P9C9/pDpwXFeD8KzyKR+cLtEJ8Apemz4pZoCBkuKzNK2/sCxIVU/RqivwGrRGI0S2i1+PNrlHjeJprcVfwOsqWm/Tqg9r64A2Rz6P1TWbifzyMtwtoEJHBu0TdfVxMfu8Gf44SxdKrBfGJ22pW0eYSdQOj6EpTSVR6LfqyC5X6BJxI2JBfFHDQB0IyCb1liId+lv7pUZumWtwtGMBnW8=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 BrvIRTeYdqAcMbv7PGzmxpg9X1yAF7zJH5FpHyXiEQxVV2S53Yg0r8Z9c/XmUHDffglA5SU53KM+WMF1lJpj2Np5dKDB6C9izin9/rPnJIUmZY9QS6Vqhtyyw5pER3cITlDARvC1bCVaETM+Y7PxJabEzhxAnM69E0O5QHnmTwEhFtMNe61cAiNlM6R0uWcczDAOQ2fDcEe95j357A4MGw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
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: ef50f147-c81a-4fef-c7cd-08d979da4bca
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2021 12:54:33.0498
 (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: DM6PR07MB7913
Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP
From: tysonandre775@hotmail.com (tyson andre)

=0A=
Hi Pierre,=0A=
=0A=
> That's nice, and I like it, but like many people I will argue about the=
=0A=
> API itself.=0A=
> =0A=
> One thing is that there's many methods in there that would totally fit=0A=
> generic collection common interfaces, and in that regard, I'd be very=0A=
> sad that it would be merged as is.=0A=
=0A=
It isn't an interface, but my previous attempts at introducing common funct=
ionality for working with iterables have failed,=0A=
e.g. with preferring userland reasons or being too small in scope among the=
 reasons.=0A=
https://wiki.php.net/rfc/any_all_on_iterable#straw_poll=0A=
=0A=
Until there's a Set type or a Map type, adding generic functionality such a=
s contains()=0A=
to all spl data structures is harder.=0A=
=0A=
I haven't seen any recent additions of utility methods to existing spl data=
structures in years other than when filling an urgent need,=0A=
(e.g. SplHeap->isCorrupted())=0A=
and have been pessimistic about that succeeding, but may be mistaken.=0A=
=0A=
> I think it's taking the problem backwards, I would personally prefer that=
:=0A=
> =0A=
> =A0- This RFC introduces the vector into a new Collection namespace, or=
=0A=
> any other collection/iterable/enumerable related namespace, that'd=0A=
> probably become the birth of a later to be standard collection API.=0A=
> =0A=
> =A0- Start thinking about a common API even if it's for one or two=0A=
> methods, and propose something that later would give the impulsion for=0A=
> adding new collection types and extending this in order to be become=0A=
> something that looks like a really coherent collection API.=0A=
> =0A=
> If this goes in without regarding the greater plan, it will induce=0A=
> inconsistencies in the future, when people will try to make something=0A=
> greater. I'd love having something like DS and nikic/iter fused=0A=
> altogether into PHP core, as a whole, in a consistent, performant, with=
=0A=
> a nice and comprehensive API (and that doesn't require to install=0A=
> userland dependencies).=0A=
=0A=
Aside: https://github.com/TysonAndre/pecl-teds#iterable-functions=0A=
starts doing that, but evaluating eagerly instead of using generators.=0A=
I still don't think there's enough functionality yet to re-propose that.=0A=
=0A=
> I know this vector proposal is not about that, but nevertheless, in my=0A=
> opinion, it must start preparing the terrain for this, or all other RFC=
=0A=
> in the future will only create new isolated data structures and make the=
=0A=
> SPL even more inconsistent.=0A=
=0A=
It's possible, but I don't know what others think.=0A=
=0A=
1. https://www.php.net/manual/en/class.ds-collection.php actually seems fai=
rly universal, but out of scope, and I don't know if people would json enco=
de a SplMaxHeap. Right now that isn't implemented and the value is always `=
{}`=0A=
2. `add($value)/remove($value)/contains[Value]($value)` is limited to some =
structures - Only containsValue() would apply to ArrayObject/SplObjectStora=
ge. The others wouldn't work since you'd need to know the keys as well.=0A=
=0A=
Also,=0A=
=0A=
- Union type/intersection type support exists, so allowing any generic coll=
ection interface is less urgent.=0A=
- equals() may work, though infinite recursion (or the way it is or isn't d=
etected) in circular data structures is a potential objection, especially w=
ith lack of stack overflow detection - php just crashes/segfaults without a=
 useful method when it runs out of stack space.=0A=
=0A=
For the ones that are universal, Countable/ArrayAccess/IteratorAggregate/Tr=
aversable already exist.=0A=
=0A=
Also, as you said, this RFC is not about that.=0A=
Requiring that anyone systematically overhaul existing data structures befo=
re adding any new data structures=0A=
seems like it would significantly delay or discourage any future additions =
of data structures.=0A=
=0A=
In the immediate future, an RFC only doing that would not have much short-t=
erm benefit to users - it would also have short-term drawbacks for what I c=
onsider not enough benefit,=0A=
if adopting that interface made libraries drop support for older php versio=
ns.=0A=
=0A=
Thanks,=0A=
Tyson=0A=