Also, you are losing a few important feature of PHP by doing this:
- Type hinted arguments (http://www.php.net/manual/en/language.oop5.typehinting.php)
- Static method calls
- Autoloading
And there are a bunch of things that would become nightmarish to manage. For example, object serialization or cloning.
Also, type hinting isn't all it's cracked up to be in PHP. In my opinion, type hints don't fit well in a dynamic language like PHP. The main problem I have is that you can't pass a decorator object to type hinted methods. Also, it makes it harder to pass mock objects for test cases.
Static method calls are possible, you can just add and call methods on the class object.
Autoloading probably isn't too hard to figure out.
You make a good point about serialisation. Closures can't be serialised. To be fair though, you can't do it in Javascript either.
Fair enough. I can appreciate that you have done an interesting bit of hackery here. Along that vein, you might consider adding support for uniform access. With this, methods without arguments can be called as properties, and properties could be exposed as read/write or read-only.
> Also, type hinting isn't all it's cracked up to be in PHP.
This is a matter of taste, but I completely disagree. In my opinion, type hinting is one of the redeeming qualities of the language. It means that PHP is taking care of the sanity checks for you. Of course, I'm partial to strongly typed languages.
> The main problem I have is that you can't pass a decorator object to type hinted methods.
Polymorphism allows you to do this. In the context of decorators, that usually means defining an interface.
This doesn't work if you have a generic decorator class. You can't really make it implement all the interfaces you potentially want to use.
It's the same problem with mock objects in test cases. You can't pass them because the type check prevents it, even though in practice everything would work just fine.