Hello Stanislav,
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
problem I assume you have in mind as well is that replace might be
implemented in a way that it uses both delete and add. If now add gets
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
used function from getting renamed. But all I just said does not really
sound like the PHP approach. It is something I would do in my own language.
In PHP we always allowed all kinds of nasty. We even hesitate to increase
the severity of any E_STRICT. Not even if it would be better for opcode
caches. We not even get rid of the insanest stuff... So where do we want to
go today with this?
marcus
Tuesday, February 19, 2008, 11:58:06 PM, you wrote:
>> most important issue to me how to handle interface implementations in
>> cases where methods from the interface implementing trait are renamed in
>> the trait consumer class.
> Renaming poses problem not only with interfaces. Imagine trait having
> these methods:
> function add($key, $value) { ... }
> function delete($key) { ... }
> function replace($key, $value) { $this->delete($key); $this->add($key,
> $value); }
> What happens if add() is renamed or replaced with function from other
> trait/interface or dropped?
> --
> Stanislav Malyshev, Zend Software Architect
> [EMAIL PROTECTED] http://www.zend.com/
> (408)253-8829 MSN: [EMAIL PROTECTED]
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
