Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116975
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] Re: Adding `final class Deque` to PHP
Thread-Index: AQHXraUxaK1dZ0niuECOJlLUpHNcpax/lZKygAAgIQCAAXQbEIAAUYgAgABVLcc=
Date: Thu, 3 Feb 2022 01:41:18 +0000
Message-ID:
 <DM6PR14MB415518F156B60EF7B3CF5BD0F9289@DM6PR14MB4155.namprd14.prod.outlook.com>
References:
 <DM6PR07MB66185E23B803C5E5BF858B30F9DF9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <DM6PR14MB41556131E6A9D7812854AA75F9269@DM6PR14MB4155.namprd14.prod.outlook.com>
 <1c9e79d5-fd79-45a8-9c77-4228d770062d@www.fastmail.com>
 <DM6PR14MB4155E8620E5907BDA2320B7EF9279@DM6PR14MB4155.namprd14.prod.outlook.com>
 <CAMrTa2EFvwLucE9K+trOpOUAtLD1x_c+CXpogAhW5QXbg5CrLw@mail.gmail.com>
In-Reply-To:
 <CAMrTa2EFvwLucE9K+trOpOUAtLD1x_c+CXpogAhW5QXbg5CrLw@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
suggested_attachment_session_id: 06dcbfa4-75a4-5bd3-7968-d4ea90868049
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn:
 [UfOTCIe/WzRfhbeAfdq0H/tNiyoMcnlLEeEnOjE4hAo+lyYR6Xs/nzUqi5g6T7gqS12xiUm0OLI=]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 77cf90b1-91bb-4167-b00f-08d9e6b64627
x-ms-traffictypediagnostic: CH0PR14MB4882:EE_
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 hK3tYDnUW3MQ6++bFjbSwVF8p2WzzEsgbVtThjG6mn+ImQalPZS4VL35urztCdoP7cYI/Yfx6GuUgyf+XvFYLftMYPCdiKijYsAmGuHYep9TvGMOohEcIiHVl0t23b0DbMpmQsPlnkuNsu5SzqUMoFq9PmqInrDh4pVWHpozc2a28ns3Knym8NFzv32luvzeA6azTp7WIHesFPl1SykILgh04Ao1Mhd8ol3tgTapHfyW2SvL10P3sn7iwPnehvP7CU5aBshda3g7GRWdV96iKZGPgTMfayEYSbDbVzfFHTDW2uqx1UBJbhrblNR05+JgPCxf+Y1lrQBvBi9Me0QYtSJAPZPFWqUdL1lZgw4jOzZVwYJ5IgK5DQxqBmzDzRYqYGxrK4o5cEDlgzF88eDdZPa/Ffl66ZGjn/oikwe4wsRtGcaLKExtqvasOIh/cuVPwkOR/DJYjZIAWrSA6s4kQ6BGUViNhGzS+rXk5xdqvj7Htzd6T910V8HtXqCGyNFoeEC0N92b9iU0hwU+N93VAyMqCamtLBLplK3w7twwCPnjL5e4xeEHD1Xg6OjCya3XoNwmVWKJ8c4QwWint8Yfs+5F+5APUbENQmvdDwhkpny/XBBA7oEOTpozG0PHisXlQ+zuufq3nDnxl/MKnp+JDZPhxbyXfxfP0LcSNNoepeA=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?uh5cySoN8ld6pOtVzmVOStk7O/AfgAEQjXjUE7Bn/1V+/6jKCuRJovVE/y?=
 =?iso-8859-1?Q?BSfr1kOcqC3QhFnqcpYI9bVneLRlmng8RNAWPvi8iMOGxDwWLBjLr04/wO?=
 =?iso-8859-1?Q?Yn9GA7IfXdpBuC7h2jWn1QIgON8QyXwVtoAHP3TtHfV+05nN0FwgWKLseM?=
 =?iso-8859-1?Q?HtSz1qRIVBOJvjScpsSuaJ7PgqgTpBPA9YotaWGOgbZnTSGWfik15c9saS?=
 =?iso-8859-1?Q?qbjXaqFNPjstzA5a+GNCX8Wro0SzvaBP97orRtSHtsKfauHmLAWmTMTreM?=
 =?iso-8859-1?Q?+uNwnDsr+TRv6Uz0CVqcugACGoTnBpgZDGeRzB6ulpNaLA718IewbdhAqh?=
 =?iso-8859-1?Q?NKeLZYnXr2ntWmTO5GP9P9/x1pWI7BS3k6b61Ns+/nOw+y/6TKzxBYAq3E?=
 =?iso-8859-1?Q?4wryWqeh/k8CoinzIkRKLeKxLGBLNj+1uLl9xD1Unhrabkd4hgJb/AzRyM?=
 =?iso-8859-1?Q?tpxea9D4E1AbEiWg+lk8Sk+Gu7Y6Yoi7XiuiD67jmRXoSPBVl+3+dwj0HS?=
 =?iso-8859-1?Q?5uBo8hOM87MhfvXXVlFKjAw8ZbrZ47kPOzY8OXmHkU09LbTqd0f4RTEXaO?=
 =?iso-8859-1?Q?jzK5ab/Zip+3rBDIFAZFNUchBOV5Ob0HBIS2BOXEXXmOH+X3vLxYJBV7dc?=
 =?iso-8859-1?Q?7SPT4otV2n9YuiMr5bnooo+yrTc6HrKDS5KieIPJ7I4bYIE3VbtyVwLoMh?=
 =?iso-8859-1?Q?T+iSpX3Uk0kPsJnH5F2dZRMB+tvihWEynK95k6bBxdMSOpgZ2rtjqxBZf6?=
 =?iso-8859-1?Q?VThd8TCFWXieqqqOOr2Qt44ANDmJbKvwEpQ700g+PXJJwMdn7DpHX6lwk9?=
 =?iso-8859-1?Q?PVTUGWPrflmlyJY/wF6Vul4DkYF3QAQP1LX2nBZsEOMRPEfhjj2/2PqjCV?=
 =?iso-8859-1?Q?Uu9zC9iWsEX8/GNUMLVYOcvssSKWwikUt/jJGI2RwfJZuguHYy+yHMtY0B?=
 =?iso-8859-1?Q?CIGLkSjOGs8REWJVgt41fRHjv1C/762Dc2CpxPj3NG2c0+mcUPgJH2+Qa/?=
 =?iso-8859-1?Q?fjXrG8oPbdc1nIvXHTovEzjbQiFu+vknqoUe0kEU/6uAo9IgRvVk/VO3fs?=
 =?iso-8859-1?Q?hw=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-cd57b.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR14MB4155.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 77cf90b1-91bb-4167-b00f-08d9e6b64627
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2022 01:41:18.4753
 (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: CH0PR14MB4882
Subject: Re: [PHP-DEV] Re: Adding `final class Deque` to PHP
From: tysonandre775@hotmail.com (tyson andre)

Hi Jordan,=0A=
=0A=
> > 4.=A0 Returning $this makes code easier to write at some cost to readab=
ility - Developers new to php or using `Collections\Deque` for the first ti=
me would not immediately know what the code they're reading is doing.=0A=
> > =A0 =A0(less of a problem with a good IDE, typechecker, and a typed cod=
ebase, but this isn't universal)=0A=
> > =A0 =A0Having it return void, `return $deque->push()` would be less com=
mon and this would force the meaning to be clear.=0A=
> > =0A=
> > =A0 =A0Developers might have several guesses/assumptions based on their=
 experience with other methods in php/elsewhere=0A=
> > =0A=
> > =A0 =A0- It returns the new count (JavaScript Array.push, array_push)=
=0A=
> > =A0 =A0- It returns $this (Ruby)=0A=
> > =A0 =A0- It returns a lazy copy, like you'd wanted, not modifying the o=
riginal=0A=
> > =A0 =A0- It's returning void and the code in question is shorthand for =
`return null`.=0A=
> > =A0 =A0 =A0(Python, C++ https://www.cplusplus.com/reference/vector/vect=
or/push_back/ , offsetSet and spl push()/shift() methods)=0A=
> =0A=
> =0A=
> I'm not sure that I buy this as a point even. Returning an immutable Dequ=
e instance would be much more in line with modern PHP in general.=0A=
> =0A=
> A major complaint about my operator overloads RFC was how it impacted sta=
tic analysis tools. I don't see how in one RFC we can say that creating wor=
k for static analysis tools is a blocking problem, and in a different RFC s=
ay that the ability to inspect the return values by the developer can't eve=
n be assumed. If we design one feature around the idea that a basic IDE may=
 not even be used, but design a different feature around the idea that we w=
ant to minimize the impact to a third party tool that provides static analy=
sis as part of workflow that's not even part of an IDE... well that seems l=
ike a very inconsistent approach to me.=0A=
=0A=
There's a difference between=0A=
=0A=
1. https://externals.io/message/116767#116768 =0A=
=0A=
   One contributor to a static analyzer thinking it would not be worth the =
complexity it adds to support in static analysis =0A=
   (and making type inference either vaguer or inaccurate for operands with=
 a type `mixed` *more frequently*)=0A=
   Debuggability seemed to be their bigger objection.=0A=
=0A=
   As a maintainer of a different static analysis tool, I'd disagree with t=
hat being a blocker, though. It'd be inconvenient to implement but would ge=
t implemented.=0A=
2. Aiming to "cater to the skill levels and platforms of a wide range of us=
ers", considering benefits/drawbacks to both groups of users (with/without =
static analyzers).=0A=
   (https://wiki.php.net/rfc/template)=0A=
=0A=
I don't think I'd have much success in an RFC adding immutable datastructur=
es, though.=0A=
=0A=
Though interestingly, they do seem possible to implement with better perfor=
mance (https://en.wikipedia.org/wiki/Big_O_notation) than I'd have expected=
.=0A=
Google searching mentioned Relaxed Radix Binary Trees, an immutable datastr=
ucture surprisingly claiming performance near arrays in most operations.=0A=
https://hypirion.com/musings/thesis https://github.com/hyPiRion/c-rrb=0A=
=0A=
Aside: An Immutable Map/Set would probably have a stronger argument than im=
mutable sequeunces/deques/linked lists (arrays support copy on write alread=
y so the original array is immutable, but arbitrary keys are something arra=
ys don't support),=0A=
but voters that didn't see a use case for immutables in core might be uncon=
vinced.=0A=
=0A=
> Either modern development tools are factored into the language design or =
they are not. This seems like a "having your cake and eating it too" situat=
ion.=0A=
=0A=
The language design is decided by what the set of voters that voted on a pa=
rticular RFC would approve with a 2/3 majority.=0A=
Voters have a wide variety of backgrounds and projects/libraries that they =
work on, and RFC authors have to guess at what those backgrounds are and wh=
at functionality would be accepted, or why similar past RFCs were really ob=
jected.=0A=
=0A=
The preferences, backgrounds, and paradigms preferred by voters vary and I =
likely won't know what those preferences are or how many voters there would=
 be until a vote is started. (e.g. frequency of writing new code vs maintai=
ning existing codebases vs working with third party libraries)=0A=
(e.g. **I won't know if anyone is strongly against fluent interfaces, or sp=
ecifically strongly against adopting fluent interfaces in an ad-hoc way, wi=
thout a policy RFC** such as the one that passed for namespaces=0A=
https://wiki.php.net/rfc/namespaces_in_bundled_extensions)=0A=
=0A=
The fact that the closest look at the design/implementation for complex RFC=
s sometimes only happens shortly before/after the start of a vote is also i=
nconvenient for authors, but hard to change with a volunteer-based process.=
=0A=
=0A=
This has downsides for current or future RFC authors, but I don't have any =
productive ideas for how to change the process that wouldn't split developm=
ent or be burdensome to voters. (and would actually be accepted)=0A=
=0A=
Regards,=0A=
Tyson=