Hi Stas, Answers inline.
On Sun, Aug 14, 2016 at 5:14 AM, Stanislav Malyshev <smalys...@gmail.com> wrote: > Hi! > > > 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 > > Object orientation is a very broad term. You can be very well object > oriented language and not be Java. In fact, almost all OO languages are > not Java ;) And a lot of OO languages (most of ones I know) don't have > Javaesque features like private classes, many also do fine without > generics. > I agree that we shouldn't copy and paste features as is. However, whenever a need is found and there are common agreement over the existence of a feature, we need to understand the decisions over each one and how are they valid for PHP. I'll draw 2 simple examples: 1- Generics: They solve a very interesting problem that is highlighted by the usage of strict types. It also hardens the implementation code, allowing to write more robust and reliable libraries that could be used by others. However, should it be a blind copy of Java generics? Of course no. In the context of PHP, lower bounds, lower bounded wildcards, unbounded wildcards and upper bounded wildcards make absolutely no sense. Now let's suppose people decide to implement polymorphism in PHP and everyone agrees with it. All of a sudden, lower bounded wildcards would become a necessity. > > > 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. > > Please do not forget that PHP was designed as beginner's language with > low barrier of entry. Making EJB out of it goes contrary to that, and > introducing features that would serve 0.01% of very complex cases while > complicating the language model for 100% of the users does not seem to > be worth it to me. > Especially if in those 0.01% cases I don't see a lot of real > improvement, but rather a "good feeling" that you can write "really > strict" code even though there's nothing better in that code than if it > were written without all the complexities. > A realization that needs to be made is that beginners would be using libraries that requires to make valid restrictions, preventing those beginners to mess up with code they shouldn't. So even if the use case is only valid for 0.01% of code producers, it might be valid for 20%+ of consumers. > > > 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 would like to see what is impossible to implement in PHP without > private classes. I mean useful functionality, not circular reference "I > need private classes because I need classes to be private" of course. > What application can not be implemented without it? I have very hard > time imagining such application. > It's not about being possible or impossible. It's about to prevent unexpected breakages and headaches that sometimes you're not even aware. It's about defensive programming. I never knew TopologicalSorter was used by several users until I actually broke its API. Imagine the frustration of all those developers with tight deadlines having to deal with a sudden breakage, because the language it too open to notify them about something shouldn't be used. Every time someone questions me about the validity of private classes, I like to exercise replacing the term "private" with "final". Final is part of PHP language and it also there's non application that is prevented without it. Doctrine's code, taking advantage of "final" modifier also allowed Zend Framework to take the right path in their implementation. We carefully think about everything we implement there, always making sure defensive programming is used for every class. Now if it was not for the existence of "final" modifier, https://mwop.net/blog/2012-06-28-oop-visibility.html history would be completely different. The same would happen for "private" classes. It prevents consumers of taking the wrong approach when developing their apps, other libraries, etc. > > > 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. > > You can document it and talk to your users. PHP is an open-source > software, with open code and open development model. If the code is out > there, people can use it. If they use it contrary to maintainer's > recommendations, they take a risk. But that's it. > > Obviously, if the users used that class, it provided some functionality > they needed. If you removed that functionality, now the users don't have > it. It's not a problem that can be solved with access modifiers. In > fact, if there were access modifiers preventing users from using > necessary functionality, they'd probably fork the code and removed them. > > Also, working around namespace-private classes is very easy - just put > your own code in the same namespace. Works for Java too IIRC. > That's not about preventing for no reason and it should be bypassed. It's about somehow telling users that something shouldn't be used at all. The amount of people that takes the wrong approach is insane, and any kind of prevention to do it is beneficial. I managed big teams of development where I work, and controlling code produced by 40+ developers is not easy. Countless classes are marked as final and I bet hundreds would be final if I could. Handling a company source code is easy through code reviews, and also walk a few steps to ask why a certain class is final or (hypothetically, private). I've walked through several scenarios of peers coming to my desk asking to remove final because reasons and going out with a much simpler solution without the need to remove it. > > > 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 > > This is a whole bunch of things here. First of all, annotation parser is > a solution for a problem that shouldn't exist - namely, lack of > annotation support. Second, the number of code that needs to pre-process > other PHP code in PHP is minuscule compared to code doing other things. > Problem of lack of Annotations support... I've tried several times, and made sure I was accessible enough to answer every situation or scenario Doctrine faced and reasons for every decision taken on the library. Still, people seem to ignore expertise and decide to take their own methods which only solves (I'll use your numbers now) 0.01% of use cases. > > Third, I'm not even sure what "allowing to assess imported/used structs > when declaring a class" means - why Doctrine annotation parser declares > a class? What are "structs"? What use has to do with class declaration? > What does Doctrine parser needs to assess, actually? I'm confused. > When I mentioned allowing to assess imported classes, I mean this: namespace Foo; use Bar\Woo; /** * @Woo\Fuzz() */ class Lala {} Annotation parser needs to understand what was "use"d, so it can properly refer to FQCN. That way, we need to somehow discover something that is only available at source (and never at post-compile time) to know that you used "Bar\Woo" when I'm processing "Lala" class. This is what TokenParser class does: https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/TokenParser.php By the lack of language support, library developers need to implement creative ways of solving problems that shouldn't exist. > Fourth, I very much question the assertion that this is the use case > library developers face *daily*. I've developed many libraries in my > career, and I never had to face this particular issue (unless, of > course, in my confusion - see above - I misunderstood what the issue 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. > > Not because *I* don't *like* it - but because this is not the right way > to do it. If you create a car with square wheels, I'd say it won't drive > well not because I hate squares but because I know round wheels drive > better. It's not a question of my personal aesthetic preferences. > > > 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 > > Before getting to the question of how, we need to pass the question of > why. And that I think is much more important. > > > 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. > > Why do you assume this resistance is "blind"? Please do not fall into > temptation of imagining your opponents as incapable of reason. This > would not get us very far. No, there are very good *reasons* for > opposing complicating the language, copying Java features that make very > little sense in PHP context and overhauling the engine and introducing > massive complications to serve a tiny percentage of use cases, even > those probably produced by lack of a different feature (also lacking > because of rejection of simple solutions in a quest of building > complicated one that serves 0.01% of most complex cases). > > -- > Stas Malyshev > smalys...@gmail.com > -- Guilherme Blanco Lead Architect at E-Block
