Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112832
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: Straw poll: Naming for `*any()` and `*all()` on iterables
Thread-Index: AQHW1kOROymHHd+jAEaQQL1oN/KEl6ohIlm2
Date: Sun, 10 Jan 2021 16:52:58 +0000
Message-ID:
 <DM6PR07MB6618DE94F0D4CC6818C39536F9AC0@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <DM6PR07MB661827026586104D5DEDAA64F9C20@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To:
 <DM6PR07MB661827026586104D5DEDAA64F9C20@DM6PR07MB6618.namprd07.prod.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [m6WPHJDExfcny0eHSspYSyPPK99a8r0MjgwzM/9n53hxny0tDFHqys8Soqw3yCca]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 6ea9fa15-f054-4739-edae-08d8b5882f43
x-ms-traffictypediagnostic: MW2NAM12HT037:
x-ms-exchange-minimumurldomainage: externals.io#1652
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 dPa8tTYqBmD6CCTF2tIE39m/L3XnOC33qV6tL4224kDbwT6BoKyDFFJxSGJBE1zQ1qyVCmta4qFMUozwSHUvLIEhU+Cj/7UmHOZtH86nPPCQP2vazlhU473JEauebxendQznH4SXqwzN9qZMe6K+E760kOxcZKv5GVUaC2XwyoivGleY1cgXHZR0jyHEMTTwQT4Ak7zpHatCSI2ofW/ozKZy66lRLvwR6dB/fXCaxGbEoLwprl35JJb2l4LqE6/0vXFxwTypOWewutAJWFyNvqqhLtL4fUI6IwC421morCI=
x-ms-exchange-antispam-messagedata:
 soZAKh8hXK8UQ+gXEy+1VK358kkIX2M+izo1Q4syR8KKFM0QU88g7cfPqC/IhJ3ZwB5EDy/14P1bdbJG5qvH8nj589CyfUBt3bW+e8msp05Zz5i6KYe1GQ8ZT5L0XPmWYaDj5b2Ex1fbJkPg2QMITknVWXl652Rmzw1MqvJ2/WZPW+4HWZqpnMh18AqjbjXsOi65m75WBqA4LRZXPQlEhw==
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: hotmail.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT068.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ea9fa15-f054-4739-edae-08d8b5882f43
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2021 16:52:58.5316
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
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: MW2NAM12HT037
Subject: Re: Straw poll: Naming for `*any()` and `*all()` on iterables
From: tysonandre775@hotmail.com (tyson andre)

Hi internals,=0A=
=0A=
> I've created a straw poll for the naming pattern to use for `*any()` and =
`*all()` on iterables.=0A=
> https://wiki.php.net/rfc/any_all_on_iterable_straw_poll=0A=
> =0A=
> Background: The RFC https://wiki.php.net/rfc/any_all_on_iterable proposes=
 adding only two functions,=0A=
> but more functionality acting on iterables (array|Traversable) may be add=
ed in the future,=0A=
> making it important to get feedback what people feel the best choice of n=
aming pattern would be=0A=
> to avoid inconsistency or name changes later on.=0A=
> (Many alternatives were suggested in the initial RFC announcement - https=
://externals.io/message/111756)=0A=
=0A=
> From Nikita Popov,=0A=
> Using just the SPL namespace (that is, SPL\any) makes the SPL namespace a=
=0A=
> dumping ground for everything, as you said. Once you introduce an=0A=
> additional meaningful namespace in the form of SPL\iterable\any, you are=
=0A=
> better off either dropping the SPL part and arriving at iterable\any, or=
=0A=
> replacing SPL with something more sensible and arriving at PHP\iterable\a=
ny.=0A=
>=0A=
> TBH I think Tyson's original approach of not including namespaces as a=0A=
> possibility was the right one. We clearly still don't have any consensus =
on=0A=
> how to structure namespaces in PHP extensions and it doesn't seem like a=
=0A=
> question that should be resolved as a footnote of another RFC. There have=
=0A=
> been multiple RFCs one the topic, and none of them reached anything even=
=0A=
> approaching a consensus.=0A=
=0A=
I'm planning to revise https://wiki.php.net/rfc/any_all_on_iterable_straw_p=
oll_namespace=0A=
due to feedback that the proposed namespace choices differs from prior prop=
osals =0A=
such as https://wiki.php.net/rfc/php_namespace_policy and perceived interes=
t in options such as PHP\SubNS\=0A=
=0A=
Although my original intent was to add `*any*()` and `*all*()` to the langu=
age=0A=
rather than work on PHP namespace policy,=0A=
I still feel obligated to gather feedback for this specific use case=0A=
since this discussion may come up in future RFCs adding new categories of f=
unctionality.=0A=
=0A=
There'd be an unmanageable amount of options to vote among if I poll on the=
 combination of namespace and name,=0A=
which is even more unpleasant since we currently don't have a widget dedica=
ted to STV(Single Transferrable Vote) polls (that I know of),=0A=
just forms that must be submitted individually.=0A=
(e.g. is X\iter\any_value() preferable over X\iterable_any())=0A=
=0A=
- Additionally, we haven't yet determined if there's a consensus on namespa=
ces.=0A=
=0A=
My plan is to start a different STV straw poll, on=0A=
=0A=
- no namespace: iterable_any()/iterable_all()=0A=
- iter\ (conflicts with nikic/iter but was also suggested by Nikita)=0A=
- iterable\ (see below note)=0A=
- PHP\ (This deliberately uses uppercase, see https://www.php.net/manual/en=
/language.namespaces.rationale.php)=0A=
- PHP\iter\=0A=
- PHP\iterable\ (see below note)=0A=
- Ext\Spl\, as suggested in https://wiki.php.net/rfc/php_namespace_policy=
=0A=
- Spl\=0A=
- Spl\iter\=0A=
- Spl\iterable\ (see below note)=0A=
=0A=
And if there's a clear preference for a namespace, start a second STV straw=
 poll between iterable_any(), NS\any(), NS\any_value, NS\iterable_any(), fo=
r the preferred namespace.=0A=
=0A=
I've also realized that `use prefix\iterable` would be mildly inconvenient =
for users of PHP and for tooling for PHP,=0A=
but still include it as an option because it's manageable and the non-names=
paced prefix `iterable_` was preferred in the previous poll.=0A=
=0A=
```=0A=
php > namespace W { echo iterable::class; }=0A=
W\iterable=0A=
=0A=
php > namespace X { use iterable; }=0A=
=0A=
Fatal error: Cannot use iterable as iterable because 'iterable' is a specia=
l class name in php shell code on line 1=0A=
php > namespace X { use iterable\any; /* using individual functions works *=
/ }=0A=
php > namespace Y { use PHP\iterable; function foo(iterable $x) {}}=0A=
=0A=
Fatal error: Cannot use PHP\iterable as iterable because 'iterable' is a sp=
ecial class name in php shell code on line 1=0A=
php > namespace Z { use PHP\iterable as iter; }=0A=
php > namespace iterable { echo "can be polyfilled\n"; }=0A=
can be polyfilled=0A=
```=0A=
=0A=
- I don't personally see the need for having "Cannot use iterable as iterab=
le" be a fatal error (especially since that token can be used in namespaces=
), =0A=
  but I'd really prefer avoiding iterable entirely to avoid special case na=
mespaces in PHP's standard library.=0A=
=0A=
  It could be argued that the type is in some sense used by any namespace s=
o it's permissible to silently allow it.=0A=
  `namespace W { echo iterable::class; }` is `W\iterable`, so this isn't te=
chnically true.=0A=
=0A=
  It'd also be inconsistent to allow `use iterable;` but not `use int;`, bu=
t making that change is a separate proposal.=0A=
- `use PHP\iterable` would cause some inconvenience, but code can work arou=
nd it with `use PHP\iterable as iter;`.=0A=
  This may cause edge cases in IDEs, automatically generated code changes, =
etc.=0A=
- The edge cases involved in `iterable` are why I propose iter\ as an addit=
ional voting option. =0A=
=0A=
Thanks,=0A=
- Tyson=