Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113960
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Namespaced in bundled extensions
Thread-Index: AQHXC7SHipPpM/LzWUe8BgLIli8g8qqLeJKCgAAEBwCAGuoYmw==
Date: Mon, 5 Apr 2021 18:05:06 +0000
Message-ID:
 <DM6PR07MB66186811B63B4FBDF94AD4B3F9779@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <CAF+90c-CEZycXeigN9zqsFyZGMxDWVT_YU6h_OMrvORE_qLk3A@mail.gmail.com>
 <DM6PR07MB66184EA01CF9B375E44C3D53F9689@DM6PR07MB6618.namprd07.prod.outlook.com>,<CAF+90c_N=DsskYuT_i_C473dk+MrvsLRt3gzPM120A9yjyCZeg@mail.gmail.com>
In-Reply-To:
 <CAF+90c_N=DsskYuT_i_C473dk+MrvsLRt3gzPM120A9yjyCZeg@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [aBjDC7CR8JetQaWyJEGinNZkb8ruKSKV]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 7c83df00-5f1c-4fd9-92a3-08d8f85d580c
x-ms-traffictypediagnostic: DM6NAM10HT071:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 zBiYpRuMWoCWu4xcWxU6OGqg1Ns2tEiPUTBlG1jNu6iN4pPZ7+zC2VeB6s/cQXzK80UCRF8HzfPZ/EznTsK0QXtSHOT2+LjF4A33oQEmhQMJfwDy+ceMoaRKkppz7CcpCMzr5hMx9ehEu/qSIlr2t7T48UzXREEZUvjSlfDa+lJ4I2Pz09dGVdc65jk6GJq8KCXku4Ax8pzecZ35ZLPVscV6iVBF16Zc6UNFnE4b1nZQAZfnSqjsgSzfVqBQnWxL7U/sAs/we1eKeUPd7gk8j8EVrQ5VybD8U5pWIeycltTV+z/5dmUDS6ieoEvMVey2hhIXryP11X46H1Rg7LxIa1oYX417aek2F8BHMqebAy9U9nxpf9iGDlWgzWS7sfIiJzg6FZfc1GIad0kAGo3whb+b+4IrcQU+qYZ/Y6Sh8H874lk1stF8v8GGABgBlSWn
x-ms-exchange-antispam-messagedata:
 hObSrxl/N3VEtOzSGBewsOlm5QNesXf4NXaaV/7MVIpZprc45GbvaTVJORglSpv5RRA9kjd1rN7+DSVus1yDdondH5PmIqaehXBmJjAx7OOaOKmgm6DwNYbKAMstEui7Ru9isJ8q9QbLnkr08xnjsg==
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: DM6NAM10FT014.eop-nam10.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c83df00-5f1c-4fd9-92a3-08d8f85d580c
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2021 18:05:06.4871
 (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: DM6NAM10HT071
Subject: Re: [PHP-DEV] [RFC] Namespaced in bundled extensions
From: tysonandre775@hotmail.com (tyson andre)

> > The question of namespaces in the stdlib has been coming up a lot recen=
tly,=0A=
> > so I'd like to present my own stab at resolving this question:=0A=
> >=0A=
> > https://wiki.php.net/rfc/namespaces_in_bundled_extensions=0A=
> >=0A=
> > Relative to a number of previous (declined) proposals, the main differe=
nce=0A=
> > is that I do not propose a top-level "PHP\" vendor namespace, and inste=
ad=0A=
> > recommend the use of "ExtName\", in line with existing practice for=0A=
> > extensions. I believe this addresses the primary concern with previous=
=0A=
> > proposals.=0A=
> =0A=
> Both of the namespacing RFCs have been announced for over 3 weeks and I d=
on't think I've=0A=
> seen any new discussion since then.=0A=
> Are any updates planned? When will voting on the namespacing RFC(s) start=
?=0A=
> (I had some stdlib RFCs/RFC ideas I was postponing since February to avoi=
d interfering with the namespacing discussion)=0A=
> =0A=
> I'd love to have some more feedback on this RFC before opening voting. Th=
ere has been a lot of discussion beforehand, but only a couple responses to=
 this RFC...=0A=
=0A=
I didn't plan to suggest changing the direction of the RFC, so I didn't hav=
e much to say.=0A=
I guess it's an improvement from a user perspective and that splitting core=
/PECL/composer namespacing wouldn't make much sense,=0A=
especially with the ability to polyfill most core functionality in composer=
 packages (especially with PHP providing FFI, low level socket/stream code,=
 etc).=0A=
=0A=
For something like https://wiki.php.net/rfc/cachediterable I'd still be fac=
ed with the namespacing choice among multiple options if this passed,=0A=
but choosing names for everything is out of the scope of this RFC.=0A=
=0A=
- `iterable\CachedIterable` would be the most likely, although it's also in=
 some ways a datastructure=0A=
- For SPL, e.g. for a new Map type or existing classes such as SplObjectSto=
rage, =0A=
  there'd still be a number of different names such as `DataStructure\Map` =
or `Collections\Map` (DS is already used by an independent PECL)=0A=
- "When adding new symbols to existing extensions, it is more important to =
be consistent with existing symbols than to follow the namespacing guidelin=
es."=0A=
  raises the question of whether existing iterables should be aliased to a =
namespace around the same time=0A=
- 5 years from now we may have a different group of active voters, so if th=
is passed with low voting turnout=0A=
  I'm not sure if there'd still be arguments over the choice to use/not use=
 a namespace.=0A=
=0A=
For a future iteration of https://wiki.php.net/rfc/any_all_on_iterable it'd=
 help if there was known community consensus (i.e. the vote on namespaces i=
n bundled extensions finished)=0A=
=0A=
I didn't notice before, but I assume you'd still planned to summarize feedb=
ack so far in a discussion section before opening https://wiki.php.net/rfc/=
namespaces_in_bundled_extensions=0A=
=0A=
For https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard=
_spl=0A=
`use Array;` and `use String;` are currently syntax errors for the unexpect=
ed token "array".=0A=
That could be fixed in the parser by adding a special case for namespace us=
es,=0A=
especially now that T_NAMESPACED_NAME now allows `string\contains` to be us=
ed without a syntax error.=0A=
=0A=
One possible concern is what would happen if PHP implemented new functional=
ity that overlapped with a fairly well-known PECL/Composer package.=0A=
E.g. if there was already a FooDB\Client in a composer/PECL package, and an=
 independent implementation was later added to php-src,=0A=
there'd potentially be conflicting names.=0A=
Being able to implement `PHP\FooDB\Client` would avoid that ambiguity=0A=
=0A=
- Then again, other programming languages such as Python have no issue with=
 that, so never mind.=0A=
  FooDBClient\ or Foo\ or something could probably be used.=0A=
=0A=
> All symbols defined in the extension should be part of the top-level name=
space or a sub-namespace.=0A=
=0A=
This should be clarified - do you mean **the extension's** top-level namesp=
ace (e.g. OpenSSL) instead of the global namespace? I assume the former.=0A=
=0A=
Regards,=0A=
Tyson=0A=