Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123002
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
Subject: Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names
In-Reply-To: <8c650dbe-4ba6-4f27-beb2-0f63a752b024@bastelstu.be>
Date: Sun, 7 Apr 2024 00:54:29 +0900
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A27D8F2E-3BBB-4621-A58E-EF40F4F40762@sakiot.com>
References: <792b2282-b7a3-40dd-899c-daab55353316@bastelstu.be>
 <D735EDA2-2234-4D20-8BFB-E2C76F301AA7@sakiot.com>
 <8c650dbe-4ba6-4f27-beb2-0f63a752b024@bastelstu.be>
To: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
From: saki@sakiot.com (Saki Takamachi)

Hi Tim,

>> Strictly speaking, namespace is neither a class nor a method, so =
isn't it outside the scope of this RFC? In fact, RFC: Class Naming makes =
no mention of namespace naming conventions at all. I asked this because =
there was mention of namespaces in the `DOM`.
>> If I'm not misunderstanding something, I think I should clarify that =
RFCs also include namespaces.
>=20
> Namespaces are defined as CamelCase (i.e. upper camel case / =
PascalCase) in the =E2=80=9CNamespaces in bundled PHP Extensions=E2=80=9D =
RFC:
>=20
> https://wiki.php.net/rfc/namespaces_in_bundled_extensions#proposal
>=20
> The phrasing in the RFC is intentionally worded to speak about =
abbreviations and acronyms in a generic way (i.e. not specific to =
classes or methods). It naturally follows that the same rules applies to =
acronyms in namespaces, especially since they are effectively part of a =
class name.
>=20
> ------------------------------
>=20
> However I agree that it should be incorporated explicitly once the =
existing policies in the policy repository have been cleaned up and =
rewritten as a follow-up to the =
https://wiki.php.net/rfc/policy-repository RFC:
>=20
>> Once (and if) this RFC is accepted, a first new step would be to =
rephrase the text so that it reads like a policy document, instead of an =
RFC. The wording is currently exactly as in the used RFCs, without =
modification.
>=20
> That has not yet happened, though.

However, in the example from "RFC: Namespaces in bundled PHP =
extensions", the acronyms are not camelcased. e.g. `FFI\FFI`, `OpenSSL`
In other words, the RFC can be interpreted as "excluding acronyms" =
implicitly.

Just to clarify: I agree with your RFC. However, I think it is best to =
avoid vague statements where the meaning changes depending on =
interpretation, if possible.

In fact, due to some ambiguity in the namespace RFC, I couldn't decide =
whether BCMath's namespace should be "BcMath" or "BCMath=E2=80=9D.=20

Regards.

Saki=