Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116112
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: (Planned) Straw poll: Naming pattern for `*Deque`
Thread-Index: AQHXroS7YGugvAukqkKHqJ49b74ipg==
Date: Tue, 21 Sep 2021 02:19:03 +0000
Message-ID:
 <DM6PR07MB66187BFC82CF83010F795D35F9A19@DM6PR07MB6618.namprd07.prod.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
suggested_attachment_session_id: f98e8adc-3142-91c1-15d7-d5c5b2d89ea1
x-tmn:
 [a6yW15dGHTtgWmPtnSGM2QSzalPLx7OM5VlHAxK8v7Iou8gwcXJOFmgQbJyGw7xaZIryHEgXcws=]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b0013d8b-9750-4735-2dcc-08d97ca62e66
x-ms-traffictypediagnostic: DM6PR07MB4171:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 mtNQdM6pbwIL9L++PJBOJRWlC9q4sArdXHnPMVxIMip09LPIEf5f4HVODqEvRpd+GhUVacqbbdZa9Gle2U9DMWs3L7DouHC+byWN1nsp2XYYAilb8Gz9RCBtmBNVKLfpHc1ZnPqDF+BoeAF0oeCEXjXUT6SxZ1tHPOcSWoup7zgjOSVj/gY23NoFylTm2vgLdVQnU/JrISw9UYYALA04SROg1PbSdHmZdSkkv/d8aZuV0d3+/YY2GVXyaPkuSAXL/YpumRLEl6ye47z/z3zMMqfpuxYPPZcYiG9jB2SqiHRnzYgSd3F4zY3sKGICT7sUkI4uJMb4nElSMrPtVAX7dsZ2z/rMFZjylDtYZFV6jhH0fHE9mY5sPyUlhPOUAxASb5TXgqC87udbapR9ORQmsHY7pggR7ciGwUAsrlBwnR3SBTPuufkjvosaV/R3qWSsDXR4OgJZdz/Tpd0HteCJkh/PYn4rNX6nHbJN6AcRk2A=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 s5Aoh7q0+USKtzQdVSI4dMeJWnirWLUsWk97pdVQNTCURmGAfJ20HG0NtxyTQ3O20Om5ZxQ6u0ciNVdzz4l+ibKc8h5uRTAH5DSpHbegbPNPo65etPoli0G6FbdGq7SeK5ZKenPJAioP2tscbW12UHj0UPjA0TrScoHR6hJMWNJ0wJCYZGhn3t+WJX2dvf2IXoVH5GT34yUJuud6oIhoFw==
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: b0013d8b-9750-4735-2dcc-08d97ca62e66
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2021 02:19:03.3520
 (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: DM6PR07MB4171
Subject: (Planned) Straw poll: Naming pattern for `*Deque`
From: tysonandre775@hotmail.com (tyson andre)

Hi internals,=0A=
=0A=
Because the naming choice for new datastructures is a question that has bee=
n asked many times,=0A=
I plan to create another straw poll (Single transferrable vote) on wiki.php=
.net to gather feedback on the naming pattern to use for future additions o=
f datastructures to the SPL,=0A=
with the arguments for and against the naming pattern.=0A=
=0A=
https://wiki.php.net/rfc/namespaces_in_bundled_extensions recently passed.=
=0A=
It permits using the same namespace that is already used in an extension,=
=0A=
but offers guidance in choosing namespace names and allows for using namesp=
aces in new categories of functionality.=0A=
=0A=
The planned options are:=0A=
=0A=
1. `\Deque`, the name currently used in the RFC/implementation. See https:/=
/wiki.php.net/rfc/deque#global_namespace=0A=
=0A=
   This was my preference because it was short, making it easy to remember =
and convenient to use.=0A=
2. `\SplDeque`, similar to datastructures added to the `Spl` in PHP 5.3.=0A=
=0A=
   (I don't prefer that name because `SplDoublyLinkedList`, `SplStack`, and=
 `SplQueue` are subclasses of a doubly linked list with poor performance,=
=0A=
   and this name would easily get confused with them. Also, historically, n=
one of the functionality with that naming pattern has been final.=0A=
   However, good documentation (e.g. suggesting `*Deque` instead where poss=
ible in the manual) would make that less of an issue.)=0A=
=0A=
   See https://wiki.php.net/rfc/deque#lack_of_name_prefix (and arguments fo=
r https://externals.io/message/116100#116111)=0A=
3. `\Collection\Deque` - the singular form is proposed because this might g=
row long-term to contain not just collections,=0A=
   but also functionality related to collections in the future(e.g. helper =
classes for building classes=0A=
   (e.g. `ImmutableSequenceBuilder` for building an `ImmutableSequence`), g=
lobal functions, traits/interfaces,=0A=
   collections of static methods, etc.=0A=
   (especially since https://wiki.php.net/rfc/namespaces_in_bundled_extensi=
ons prevents more than one level of namespaces)=0A=
=0A=
   Additionally, all existing extension names in php-src are singular, not =
plural. https://github.com/php/php-src/tree/master/ext =0A=
   (Except for `sockets`, but that defines `socket_*` and `class Socket` an=
d I'd assume it would be named `Socket\` anyway, the rfc didn't say exactly=
 match?)=0A=
=0A=
   So the namespace's contents might not just be `Collections`, but rather =
all functionality related to a `Collection`)=0A=
   Also, the examples in the "namespaces in bundled extension" RFC were all=
 singular=0A=
=0A=
   > For example, the `array_is_list()` function added in PHP 8.1 should in=
deed be called `array_is_list()`=0A=
   > and should not be introduced as `Array\is_list()` or similar.=0A=
   > Unless and until existing `array_*()` functions are aliased under an A=
rray\* namespace,=0A=
   > new additions should continue to be of the form `array_*()` to maintai=
n horizontal consistency.=0A=
=0A=
   See https://wiki.php.net/rfc/deque#global_namespace (and https://externa=
ls.io/message/116100#116111)=0A=
=0A=
   Also, straw polls for other categories of functionality (https://wiki.ph=
p.net/rfc/cachediterable_straw_poll#namespace_choices) =0A=
   had shown interest of around half of voters in adopting namespaces,=0A=
   there was disagreement about the best namespace to use (e.g. none that w=
ere preferred to the global namespace),=0A=
   making me hesitant to propose namespaces in any RFC. For an ordinary col=
lection datastructure, the situation may be different.=0A=
=0A=
While there is considerable division in whether or not members of internals=
 want to adopt namespaces,=0A=
I hope that the final outcome of the poll will be accepted by members of in=
ternals =0A=
as what the representative of the majority of the members of internals =0A=
(from diverse backgrounds such as contributors/leaders of userland applicat=
ions/frameworks/composer libraries written in PHP,=0A=
documentation contributors, PECL authors, php-src maintainers, etc. (all of=
 which I expect are also end users of php))=0A=
want to use as a naming choice in future datastructure additions to PHP.=0A=
(and I hope there is a clear majority)=0A=
=0A=
-----=0A=
=0A=
Are there any other suggestions to consider for namespaces to add to the st=
raw poll?=0A=
=0A=
Several suggestions that have been brought up in the past are forbidden by =
the accepted policy RFC (https://wiki.php.net/rfc/namespaces_in_bundled_ext=
ensions)=0A=
and can't be used in an RFC.=0A=
=0A=
- `Spl\`, `Core\`, and `Standard\` are forbidden: "Because these extensions=
 combine a lot of unrelated or only tangentially related functionality, sym=
bols should not be namespaced under the `Core`, `Standard` or `Spl` namespa=
ces.=0A=
  Instead, these extensions should be considered as a collection of differe=
nt components, and should be namespaced according to these."=0A=
- More than one namespace component (`A\B\`) is forbidden=0A=
- Namespace names should follow CamelCase.=0A=
=0A=
Thanks,=0A=
Tyson=0A=