Hi!
if we go the route of allowing that, then we have to do some protocl checks. Meaning if a renamed/aliased method will become an implementation of an abstract method then of course it has to be compatible. The beigger
I'm kind of confused on a use case for that. Suppose you have trait TFoo that does some API - like implementing serialization, for example. And then you have some abstract method bar() that is supposed to do something unrelated - like convert pounds to kilograms. And then you just rename one of the methods of TFoo into bar() and suddenly it starts being used for converting pounds to kilograms just because it has the same argument count? I don't see any sane application structure working this way. What would be the use case of taking methods from one API and using them as implementation for totally unrelated parts of other API? What if one of the APIs changes? What if change required to implement TFoo but bar() should stay the same? This just looks like very cludgy attempt to avoid typing a few extra lines, which will definitely will come back to bite the developer in the future. I think this is important - to figure out what is the good use case for this.
dropped or renamed then there is a problem, called missing function. We could avoid that easily if we have a compiler that allowed us to check which functions are being called. Becasue then we could easily prevent a
We can't - as I already mentioned, call resolution is dynamic in PHP, which means compiler can't check which methods are called. On top of that, nobody said methods are always to be called on $this with -> operator - there are many other ways to call a method on an object.
In PHP we always allowed all kinds of nasty. We even hesitate to increase
No, we didn't allow all kinds of nasty. PHP never had dynamic method addition, dynamic object/class redefinition, etc. even though engine-wise it's completely possible. That's the domain of hackish extensions like runkit and IMO it should stay there - in it's own closet which is clearly labeled "beware of the leopard". I would have no objection for runkit to have traits-like functions - in fact, I think it can do it right now. Having this in core is another, very different business.
-- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
