Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35655
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Wed, 20 Feb 2008 21:09:40 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <194023457.20080220210940@marcus-boerger.de>
To: Stanislav Malyshev <stas@zend.com>
CC: php@stefan-marr.de, internals@lists.php.net
In-Reply-To: <47BB5EFE.4080704@zend.com>
References: <001c01c87264$3c01b4e0$b4051ea0$@de> <1203461114.24580.45.camel@localhost> <47BB5EFE.4080704@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: helly@php.net (Marcus Boerger)

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
> stas@zend.com   http://www.zend.com/
> (408)253-8829   MSN: stas@zend.com




Best regards,
 Marcus