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. > 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. > 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. > 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. > 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. 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
