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
