On 6/11/2017 1:08 AM, Dan Ackroyd wrote: > 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. >
> Introduce namespaces to user-level symbols to avoid collisions with > user defined symbols, decrease breaking changes due to the > introduction of new symbols and thus increase future compatibility. On 6/11/2017 1:08 AM, Dan Ackroyd wrote: > 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. > > An important question to answer, if namespaces are to be used by PHP, > is how they should be written. PHP has a long history of > inconsistency, it therefore makes sense to define this upfront to > ensure that any future effort is not going to introduce new > inconsistencies. > The vendor namespace itself does not contain any code directly, but > instead is split into multiple sub-namespaces. This should ensure that > we are not creating a new global namespace where everything that > cannot be categorized ends up in. > Std or util — for tiny self-contained types (e.g. > InvalidArgumentException) and functionality where it would be total > overkill to create a dedicated namespace for (e.g. UUID). On 6/11/2017 1:08 AM, Dan Ackroyd wrote: >> Coding Standard? snake_case/PascalCase > Shouldn't this be part of the other RFC? > > There are two possible choices: > > 1. snake_case > 2. PascalCase (in accordance with class naming) > > Arguments for both approaches exist, however, it is after all a purely > cosmetic question: On 6/11/2017 1:08 AM, Dan Ackroyd wrote: >> 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. > Splitting files to related things is exactly what this RFC is about. Nowhere does it state that files must be split by a line limit. On 6/11/2017 1:08 AM, Dan Ackroyd wrote: > > 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. > > Introduce namespaces to user-level symbols to avoid collisions with > user defined symbols, decrease breaking changes due to the > introduction of new symbols and thus increase future compatibility. Reserving the global namespace now cannot achieve this, because it is already in use by millions of projects out there. On 6/11/2017 1:08 AM, Dan Ackroyd wrote: > 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 > > Extensions which are provided by third-party vendors to the PHP Group > for future maintenance and inclusion in the PHP repository go into > their own vendor namespace. This should ensure that we can move those > extensions to PECL without breaking compatibility on a namespace > level. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
