It seems I'm not alone in not wanting added complexity in php.
So what? I would rather the core developers spend more time implementing Namespaces than some feature no one in their right mind would use. People would use Namespaces and people advocating subclasses can use Namespaces for such a feature.
Don’t Advocate Subclasses (Inner Classes) - SantosJ
From a 'theoretical' perspective php is weird. Really strange. It has some low(ish) level features, for example the semantics of a function, the lack of nested functions and closures, as well as high level ones - the runtime symbol resolution, .i.e. variable variables and the $$func() syntax.
More interestingly you can, if you like, use different programming styles, and with a bit of imagination, you can actually code in a very sophisticated style.
Yes, php lacks conveiniences. Namespaces for starts. The problem is not so much with syntax, but with a non-bloated implementation. For a similar effect I've been using runkit sandboxing, but the only way to communicate between namespaces is via the sandbox object variables and theRunkit_Sandbox_Parent (or via the output but that is beyound the point). Anyway, this does provide a sensible namespace scheme without introducing too much changes. Downsides? Adding a new php thread nessesarily eats more memory and cpu resources. Using a proxy class for access can prove controversioal in some circles. Goodies? No real change in the language. Convenient/natural syntax for people who already know php. Added security due to the possibility to limit what symbols are available in the sandbox.
This approach is typical for php. Scratch an your own itch, and somebody will find another, different use for that.
For example, I would love to write a dylan-like syntax rewriting macros for php when I have a bit of time on my hands. I wouldn't advocate to have them in the compiler though. It will potentially slow down the compilation, but if it is possible to add them as compiler hooks, that could be great. Anyway, caching the results would probably be the most sensible approah in a production system. I worry though, that they can easily lead to bloated code. Which is typical in a lot of php applications. I think we need a lot of education and study to recognise what are the really good patterns for practical programming in php, and how can the language be really improved.
As with class methods and
As with class methods and variables, a static nested class is associated with its outer class. And like static class methods, a static nested class cannot refer directly to instance variables or methods defined in its enclosing class — it can use them only through an object reference.
so what?
Do you mean that you could, in theory, use nested classes to substitute the lack of closures (environment capture) in php?
It's the kind of unclean language evolution that actually harms the language what I oppose. Patch over patch over patch.
Having said that, I'm not in the driving seat and not having a single contribution, even indirect, to the code base makes my opinion weightless...