Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35593
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: Tue, 19 Feb 2008 15:29:30 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <3710533306.20080219152930@marcus-boerger.de>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
In-Reply-To: <47BA34AB.6010408@lerdorf.com>
References: <001c01c87264$3c01b4e0$b4051ea0$@de> <58510.98.193.37.55.1203374232.squirrel@www.l-i-e.com> <200802181936.17739.larry@garfieldtech.com> <47BA34AB.6010408@lerdorf.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 Rasmus,

Tuesday, February 19, 2008, 2:45:15 AM, you wrote:

> Larry Garfield wrote:
>> You also note that this mechanism has no runtime impact.  That's unfortunate, 
>> because I'd find the ability to add methods to an object at runtime 
>> conditionally based on some other value far more useful in my work. :-)  
>> Especially since, as above, there seems to be a way to implement this 
>> functionality now as-is with a little more typing, yet runtime modification 
>> is still impossible without eval() and similar scary stuff.

> The idea here is that we want to be able to cache opcodes, classes and
> functions and optimize them out of the runtime context so the executor
> can skip creating classes and functions on every single request.  A lot
> of the traffic on this list over the past couple of months seems to
> ignore this basic premise.  Features such as autoload and runtime object
> manipulation incur a huge performance hit in the sense that they change
> something that was free before and not only add the cost of the feature
> itself, but it also means the object in question now can no longer be
> cached and has to be created on every single request.

> This doesn't mean we can't consider such features, but people need to
> also consider the performance implications.

For that reason allowing traits in favor of include inside a class body is
much better.

Best regards,
 Marcus