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.
>
> Namespaces are defined as CamelCase (i.e. upper camel case / PascalCase) in the “Namespaces
> in bundled PHP Extensions” RFC:
>
> https://wiki.php.net/rfc/namespaces_in_bundled_extensions#proposal
>
> 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.
>
> ------------------------------
>
> 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:
>
>> 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.
>
> 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”.
Regards.
Saki