Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116081 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 41965 invoked from network); 18 Sep 2021 01:09:15 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 18 Sep 2021 01:09:15 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6F5651804C8 for ; Fri, 17 Sep 2021 18:49:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_HOTMAIL_RCVD2, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS8075 40.80.0.0/12 X-Spam-Virus: No X-Envelope-From: Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12olkn2040.outbound.protection.outlook.com [40.92.21.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 17 Sep 2021 18:49:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B2ZJrPumZtwo0qIMOrPA8zn1oVlBGN+rd5mYzYgXpRayCPjcDuNU5Ujpw0EIAyBiQdzFtSW5YW8hH0s37Qxv731VSaBZQasehW5Ui0MTx+p6c4hCMPyuirw6PVyA82odgNbbIf2Rnys6SZnOef0FFOD289frSr8SuATgxMkByoO8c1TaWF04h9wYsYMwCOd+Dza6DadVQOM4uju8tEd1IMJxVroQJJr3VUYZ+5slB6zVZWEtrT8Xd8kHfZVv4OVfJdJIkTfC1dJfZVMiOqJ3l1ksBlTbu+S/SGUrNptKUoxwW196jkg8bbsPOgpXxcBbn9WAV4H/xZU8UQQrsvyVIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OLdSb/53tOGoXs16MzIldXZ4ysHEPb+4gmbsxwrBf34=; b=BmQkto4PDAenOQ/oPFD+oeneh7kelhPvMQsem1b035u7iUpM1crXzhZE3MrRF0f7ptjP7wYLlbh6mUg2vEmdDdCNseAkRSVlxZ1nZwt5yj68UM3nIFFZwq/a7zdYFu3FmQIkrQ1b04JjCzoqQ07w2JETawlDx/q3jXEno4eIamHvKR/+UUpc7718ecOFViPDJxI6nZX3jkWASmPxVvbqyZ8m1p/eibetpIjz74VxIUgvTZIawuaFgluuL1p1aba2v630Put5XLZ/kX0JJ6LLtJowX9Zc9PxGG5U5gM5sg/wFgF3RKiqBNEsW3Sx/15PnKKqhRoNnydqjegzE3fvCdg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OLdSb/53tOGoXs16MzIldXZ4ysHEPb+4gmbsxwrBf34=; b=srz09bPnXFisnIJy4eo1TAOXO5B8lCRNgREravTvSTZ1JVbcEWRjl4LYfWERobfQRHU9x5WwSTTnUCMNRtXk/GspIYpp5mD64Us9mvr2cKJ0Gy2FdkC1YysQ/Z/RKFin+JrG5Ao1wt8v1f9mZuQnF/lzyXMWFi6d/KQNJbNgQJHqUxSuXhPNogEHAs1v7u4ri180KQE45Z6YEral5OMWlbZIZgkV8fVjrrjrRg7FS44V/4roR7WHeVrvxjpNLjCQ7OggtZO6tsgbem33JC1s6u0lLSXpir7kwnQrT5IvHAZKzbUd1q4w0jZO/QdpG9iFB72xnEzTzUU0LVMVagzDwA== Received: from DM6PR07MB6618.namprd07.prod.outlook.com (2603:10b6:5:1cf::26) by DM6PR07MB7259.namprd07.prod.outlook.com (2603:10b6:5:222::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.16; Sat, 18 Sep 2021 01:49:16 +0000 Received: from DM6PR07MB6618.namprd07.prod.outlook.com ([fe80::7181:60db:c4d2:835]) by DM6PR07MB6618.namprd07.prod.outlook.com ([fe80::7181:60db:c4d2:835%7]) with mapi id 15.20.4523.017; Sat, 18 Sep 2021 01:49:16 +0000 To: php internals Thread-Topic: [PHP-DEV] RFC: Add `final class Vector` to PHP Thread-Index: AQHXq2Dr5ROExEhu802SAlX6zd1M+6uosVGAgABRo6A= Date: Sat, 18 Sep 2021 01:49:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: a55e1b12-68ac-31a9-2119-25e2ba9a91b1 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [giIABObZD/J6D9mA1fiO7Or6WDlxpvbtPAhLkleeXOAjZuhMqLaA7pzyUUnKnL362FYg7CP9BXs=] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 271dad5d-2015-4851-74f8-08d97a46861d x-ms-traffictypediagnostic: DM6PR07MB7259: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OidmAcarGVn+cKQWeZ98RqwkOrcReNwmbNedEPMQi0ACdjksPCIH0vlmwz2q//1J8qwbC4TMbdwrNb5F/oaUQuzfZNrZw4o/MZ+/nJ0BhJPhmaEKcn3bH/0h6QgrSSJeuLzp+0BLAseJFZYAtjtjtfvkmsWgcDdbk7x6Jj4gRHQEcTVvPprCL79NjVSwOBb6L27G2CXUS+z477EWF7zu9dqNM15LdYYSn4xJ1VMkGC0BheMVWwPza2OkLCBXYzWIVNV/HWHeoKmUFVrrC8q7aP1wZl8e/TFdm7xe7KQOAvfVkMj4TrtX2VnoEM9DoldBzbgn3DcCK3ByzvMtpLGEKsw6KPl8YSEmcgvXYR1LX+uO/OxRpC5nrRt7Ci6iCD+Jc8jMKSwYKTwKVtyUMAHIKdaMOR+qhGsqhKeChlEPCsI5uc95qCFd0kAx3SPR1qFBW56osIajH7izJdaQ4mz7eP89eDhk206kblncPjiuneN6/iIE3d9E8xDGGCK5bn+uU9gdWFKEni9TBPV9kFih/A== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: /UnyknJTUEt3jBnpI5qQ1j38HBxOz6GSIvd4NfbHE0FFkwssF8tLs0pUES3lIbYO4Uog53Vxy4ISOnYpsuQUDHGhPg9gPeJrhVt10GzAALG5paHx8NSlK0JYZdLtu4o6/0CsBysh1NOeJC79N1wTniCaZ+8iarSt5hp03nt/QqCfNPT3a6cmo44YYtOQikPWmHv9tDY5UL19gKTmeZgxqA== 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: 271dad5d-2015-4851-74f8-08d97a46861d X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2021 01:49:16.5323 (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: DM6PR07MB7259 Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP From: tysonandre775@hotmail.com (tyson andre) =0A= > Improving collection/set operations in PHP is something near and dear to = my heart,=0A= > so I'm in favor of adding a Vector class or similar to the stdlib.=0A= > =0A= > However, I am not a fan of this particular design.=0A= > =0A= > As Levi noted, this being a mutable object that passes by handle is askin= g for trouble.=0A= > It should either be some by-value internal type, or an immutable object w= ith evolver methods on it.=0A= > (E.g., add($val): Vector). Making it a mutable object is creating spooky = action at a distance problems.=0A= > An immutable object seems likely easier to implement than a new type,=0A= > but both are beyond my capabilities so I defer to those who could do so.= =0A= =0A= https://wiki.php.net/rfc/vector#adding_a_native_type_instead_is_vec discuss= es why I'm doubtful of `is_vec` getting implemented or passing.=0A= Especially with `add()` taking linear time to copy all elements of the exis= ting value if you mean an array rather than a linked list-like structure, a= nd any referenced copies taking a lot more memory than an imperative versio= n would.=0A= =0A= =0A= PHP's end users and internals members come from a wide variety of backgroun= ds,=0A= and I assume most beginning or experienced PHP programmers would tend towar= ds imperative&mutable programming rather than functional&immutable programm= ing.=0A= =0A= PHP provides tools such as `clone`, private visibility, etc to deal with th= at.=0A= =0A= The lack of any immutable object datastructures in core and the lack of imm= utable focused extensions in PECL=A0https://pecl.php.net/package-search.php= ?pkg_name=3Dimmutable=0A= https://www.php.net/manual-lookup.php?pattern=3Dimmutable&scope=3Dquickref= =0A= (other than DateTimeImmutable)=0A= heavily discourage me from proposing anything immutable.=0A= =0A= (Technically, https://github.com/TysonAndre/pecl-teds has minimal implement= ations of immutable data structures, but the api is still being revised and= Vector is the primary focus, followed by iterable functions. e.g. there's = no `ImmutableSequence::add($value): ImmutableSequence` method.)=0A= =0A= =0A= > The methods around size control are seemingly pointless from a user POV.= =0A= =0A= setSize is useful in allocating exactly the variable amount of memory neede= d while using less memory than a PHP array.=0A= `setSize($newSize, 0)` would be much more efficient and concise in initiali= zing the value.=0A= =0A= - Or in quickly reducing the size of the array rather than repeatedly calli= ng pop in a loop.=0A= =0A= And while methods around capacity control exist in many other programming l= anguages, they aren't used by most users and most users are fine with funct= ionality they don't use existing.=0A= The applications or libraries that do have a good use case to reduce memory= will take advantage of them and end users of those applications/libraries = would benefit from the memory usage reduction.=0A= =0A= > I understand the memory optimization value they have, but that's not some= thing PHP developers are at all used to dealing with.=0A= > That makes it less of a convenient drop-in replacement for array and more= just another user-space collection object, but in C with internals endorse= ment.=0A= > If such logic needs to be included, it should be kept as minimalist as po= ssible for usability,=0A= > even at the cost of a little memory usage in some cases.=0A= =0A= If the functionality was just a drop-in replacement for array, others may s= ay "why not just use array and the array libraries?" (or Vector).=0A= With the strategy of doubling capacity, it can be up to 99% more memory tha= n needed in some cases (Even more wastage after shrinking from the maximum = size).=0A= =0A= > There is no reason to preserve keys.=0A= > A Vector or list type should not have user-defined keys.=0A= > It should just be a linear list. If you populate it from an existing arra= y/iterable, the keys should be entirely ignored.=0A= > If you care about keys you want a HashMap or Dictionary or similar (which= we also desperately need in the stdlib, but that's a separate thing).=0A= =0A= The behavior is similar to https://www.php.net/manual/en/splfixedarray.from= array.php =0A= It tries to preserve the keys, and fills in gaps with null.=0A= =0A= 1. There's the consistency with existing functionality such as SplFixedArra= y::fromArray, or existing constructors preserving keys.=0A= 2. And I'd imagined that a last minute objection of "Wait, `new SplFixedArr= ay([1 =3D> 'second', 0 =3D> 'first'])` does what by default? Isn't this usi= ng the keys 0 and 1?", and the same for gaps=0A= =0A= =A0 =A0I was considering only having the no-param constructor, and adding t= he static method fromValues(iterable $it) to make it clearer keys are ignor= ed.=0A= =0A= > Whether or not contains() needs a comparison callback in my mind depends = mainly on whether or not the operator overloading RFC passes. =0A= > If it does, then contains() can/should use the __compareTo() method on ob= jects.=0A= > If it doesn't, then there needs to be some other way to compare non-ident= ical objects or else that method becomes mostly useless.=0A= =0A= There's a distinction between needs and very nice to have - a contains chec= k for some predicate on a Vector can be done with a userland helper method = and a foreach.=0A= =0A= Also, you're requesting functionality that I don't believe is currently ava= ilable for arrays, either.=0A= =A0=0A= > To echo Pierre, a Vector needs to be of a single guaranteed type.=0A= > Yes, this gets us back to the generics conversation again, but I presume = (perhaps naively?) there are ways to address this question without getting = into full-blown generics.=0A= =0A= Yep, as you said, this type is mixed, just like the SplFixedArray, ArrayObj= ect, values of SplObjectStorage/WeakMap, etc.=0A= Generic support is something that's been brought up before, investigated, t= hen abandoned.=0A= =0A= My concerns with adding StringVector, MixedVector, IntVector, FloatVector, = BoolVector, ArrayVector (confusing), ObjectVector, etc is that=0A= =0A= - I doubt many people would agree that there's a wide use case for any =0A= =A0 specific one of them compared to a vector of any type.=0A= =0A= =A0 This would be even harder to argue for than just a single Vector type.= =0A= - Mixes of null and type `T` might make sense in many cases (e.g. optional = objects, statistics that failed to get computed, etc) but would be forbidde= n by that=0A= - It would be a bad choice if generic support did get added in the future.= =0A= =0A= I'm not sure if we're thinking of the same thing.=0A= Could you provide more details on how that would be implemented? Have other= PECLs done something similar?=0A= =0A= > But really, a non-type-guaranteed Vector/List construct is of fairly litt= le use to me in practice, and that's before we even get into the potential = performance optimizations for map() and filter() from type guarantees.=0A= =0A= See earlier comments on `vec`/Generics not being actively worked on right n= ow and probably being a far way away from an implementation that would pass= a vote.=0A= =0A= As for optimizations, opcache currently doesn't optimize individual global = functions (let alone methods), it optimizes opcodes.=0A= Even array_map()/array_filter() aren't optimized, they call callbacks in an= ordinary way.=0A= E.g. https://github.com/php/php-src/pull/5588 or https://externals.io/messa= ge/109847 regarding ordinary methods.=0A= =0A= Aside: In the long term, I think the opcache core team had a long-term plan= of changing the intermediate representation to make these types of optimiz= ations feasible without workarounds like the one I proposed in 5588=0A= =0A= > I can write a type-guaranteed user-space class that does what I need in u= nder 10 minutes, and for most low cardinality sets that's adequately perfor= mant. A built-in needs to be better than that.=0A= > =0A= > I very much appreciate the chicken-and-egg challenge of wanting to get so= mething useful in despite the absence of a larger plan, and also the challe= nge of getting buy-in on a larger plan.=0A= > Really. :-) This is an area where PHP's current dev process is very lacki= ng.=0A= > Still, I also agree with others that we need to be thinking holistically = about this problem space, which will inform what the steps are.=0A= > The approach we took for enums could be a model to consider (multiple RFC= s clustered together under an RFC "epic".)=0A= > That would allow for a long-term design, and the influence that offers, w= hile still having milestones along the way that offer value unto themselves= . (I'm happy to help with that, since that's about all I'm good for around = here. :-) )=0A= =0A= Enums were extensions of existing class types (is_object(Suit::Hearts) is t= rue) rather than adding a whole separate type to the type system and don't = need to support generics or contain anything other than an int/string.=0A= I don't think the choice of "epic" widely influenced the vote.=0A= =0A= Regards,=0A= Tyson=