Hi 'Fleshgrinder', I object to this RFC on principle.
RFC's are supposed to be opionated. They are supposed to present an argument for why we should do something, and why doing that is a good idea. This RFC does not do that; it presents a series of questions to vote on, without any clear presentation of what problem they are solving or why people should be vote for the RFC. Asking people to vote on things like this, leads to choice being made at random, when there may not even be a need to make a choice in the first place. These parts of the RFC are particularly lacking justification: > Allow plural nouns in namespaces? Yes/No > Use namespace for the language itself (in the future)? Yes/No > Name of the language namespace? core/lang > Use namespace for tiny self-encapsulated things (in the future)? Yes/No > Name of that namespace? std/util In addition, there are problems with other parts of the RFC. > Coding Standard? snake_case/PascalCase Shouldn't this be part of the other RFC? > This could help to avoid those 1,000+ LOC files Splitting files to only contain related things is a good idea. Splitting related things into separate files, just because some arbitrary line limit has been reached, is not. >From the RFC: > Introduce namespaces to user-level symbols to avoid collisions with user > defined symbols > > Use namespace for the language itself (in the future)? Yes/No > >From email, Fleshgrinder wrote: > I personally do not like this approach. PHP is the vendor of these > things, thus, it should reside in the namespace of the vendor. Same > rules for everyone. If this is actually problem, a better solution might be just reserve the global namespace in addition to the 'PHP' namespace. However the RFC does not say why it is a problem that needs addressing, and so we cannot explore possible solutions. Multiple people have given you feedback that your idea of using a top level 'PHP' vendor namespace isn't a good match for the project. Rather than rephrasing what they have already said, I will just remind you of an earlier reply: >From http://news.php.net/php.internals/98225 On 2/6/2017 9:47 PM, Nikita Popov wrote: > > I'm strongly against use of the PHP namespace as a blanket namespace > for bundled PHP extensions. The PHP namespace should be used only > for functionality that is actually in some way related to PHP. For > example, the php-ast extension could reasonably be namespaced as > php\ast, as it provides an AST for PHP specifically. Similarly the > tokenizer extension could reasonably be namespaced as php\tokenizer. > > Extensions which are not of this type should not live in the PHP > namespace, because they don't have anything specifically to do with > php, apart from the circumstance that they happen to be bundled at > the current point in time. Remember that extension may move from > being bundled to being in PECL and vice versa. If we decide to bundle > the MongoDB extension with php, would we rename the currently used > MongoDB namespace to PHP\MongoDB? If we decided to move it back to > PECL, would the namespace go back to just MongoDB? Or would it stay > PHP\MongoDB, despite not being part of PHP anymore? Should all new > extensions be written with a PHP namespace to account for the > possibility of the extension being bundled with PHP at a later point > in time (even if there are no concrete plans to do so)? > > I would answer No to these questions. The namespace MongoDB is not, > as you say, "random", it is *meaningful*. The namespace PHP is (with > the exceptions in the first paragraph notwithstanding) meaningless > and an artifact of the distribution mechanism, a mechanism which may > change over time. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
