Hi Stas, I'll answer your message as it directly refers to links with my name. I understand the reasons of why namespaces were implemented that way, as I follow this list for quite a long time. I never complained about the implementation itself as it was publicly introduced originally back in August 2008, when first PHP 5.3 alpha 1 got released.
Today I see 2 sides in PHP Internals. One that truly believes that PHP should adopt more concepts of object orientation, such as Annotations, Generics, Overloading, Class visibility, Collections, Exceptions, etc (the side I support) and the other side that wants to make the engine more robust, stable and faster, without entering in a rollercoaster of new functionality to be introduced that brings instability. One thing that didn't change is the constant increase of developers writing and rewriting software using the language. Now these developers are also improving their skills, and demanding more flexible ways of achieving their needs. Language evolution should also be in compass with these new needs, and that's where I think PHP is struggling to keep up, for a variety of reasons. Being a constant contributor to open source and many libraries that now drives most of what people consider as "Modern PHP", I constantly face problems with the language itself being unable to achieve my needs. When I say my needs, I mean needs of heavily used libraries, with hundreds or thousands of other projects depending on them. I'll highlight the main driver of "private classes" conceptualization, in an attempt to make this email short (which I already failed). I wrote a DAG sorter as part of one of Doctrine packages. Many people started to instantiate (and use this class, even though it was marked as an @internal) and consume the benefits it provides, until I changed its API working on a bug fix. If this class was never intended to be used outside of the scope of this project, how can restrict its usage by outside packages? Feel free to provide me answers or alternatives, and I'll happily agree with you that private classes is a bad idea. Namespace implementation is now the blocker of many new features that could help solve complex problems that you don't see on a daily basis, but library developers face daily. For example: allowing to assess imported/used structs when declaring a class would drastically reduce the complexity of Doctrine's annotation parser, which required token_get_all and several logic to check for what you're including. Is there a better solution for that too? Well, I'd argue Annotations has a market, and people are just blind if they don't wanna see it. Answering that implementing Annotations in userland is a bad idea is like telling a corporation shouldn't create a product because you don't like it. Makes absolutely no sense. I do have a lengthy, detailed and complex plan of how namespace refactoring could be made, what it would enable feature-wise, and how it would benefit many projects. I'm open to share with you or any other internals developer, assess impact over PHP source code and even help implementing it. I'm just unable to do it all by myself due to my poor C knowledge. What I don't want to see is blind resistance to language evolution and blaming over something as badly designed without understanding the circumstances that drove to that implementation decision. Regards, On Sat, Aug 13, 2016 at 3:20 PM, Stanislav Malyshev <smalys...@gmail.com> wrote: > Hi! > > > The current approach to namespaces blocks new features like you see it > > in the following PR. The link already points to the two most relevant > > comments that should give you full context: > > > > https://github.com/php/php-src/pull/947/#issuecomment-224912697 > > I don't think this - private classes, etc. - is a good idea. It looks > like Javaization of the language and introducing more and more > complexity without any clear benefit, and AFAIK none of the mainstream > scripting languages have such concept. Anyway, this doesn't even have an > RFC, so I don't see why we should refactor everything to accommodate it. > > But it is certainly does not fit the concept of namespaces. It needs > completely different packages concept - one that currently does not > exist on PHP. Trying to bolt it on existing concept is not going to do > any good. I think this is what it should start with - developing a good > concept, not trying to go from code modification to design. Design > should come first, then code modification. > > > You might know other approaches to solve this. What I want to say is, we > > should not re-discuss everything that was discussed before, we should > > discuss the proposed features and refactor the namespaces IF it is > required. > > Indeed. > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Guilherme Blanco Lead Architect at E-Block
