Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35738
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain cschneid.com from 195.226.6.51 cause and error)
Message-ID: <47BF05FC.4020903@cschneid.com>
Date: Fri, 22 Feb 2008 18:27:24 +0100
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: RQuadling@GoogleMail.com
CC: internals Mailing List <internals@lists.php.net>
References: <001c01c87264$3c01b4e0$b4051ea0$@de>	 <58510.98.193.37.55.1203374232.squirrel@www.l-i-e.com>	 <b5f7bf6c0802181508j7124be3y92800e15a25f9497@mail.gmail.com>	 <33475.98.193.37.55.1203621640.squirrel@www.l-i-e.com> <10845a340802220300t50072babh43ca299010147808@mail.gmail.com>
In-Reply-To: <10845a340802220300t50072babh43ca299010147808@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: cschneid@cschneid.com (Christian Schneider)

Richard Quadling schrieb:
> On 21/02/2008, Richard Lynch <ceo@l-i-e.com> wrote:
>>  In fact, new users are often confused because the CAN'T do an include
>>  in the middle of a class -- A rule which, to some, seems arbitrary and
>>  illogical.
> 
> And once they understand (if they do) why they cannot use "include",
> they want to know how to do it anyway.
> 
> Traits answer this quite nicely. All be it in a way which the idea of
> include would solve if it was done at parse/compile time.
> 
> So, maybe something as simple as
> 
> class_include 'file.inc';

We even would not need a new keyword, we could use "include" for this. 
The user would not really care if this is compile time or run time as 
long as the simple (and most useful) case Just Works IMHO.

> But having said that traits LOOK nice. They look clever.
> 
> Is it over complicated? If you don't know OOP, then maybe. But hell if
> everything was easy we would have monkeys doing it all for us.

I'm trying to suppress my reservations about new language constructs and 
was quite succesful: I started to like Traits. But the discussion about 
the semantics are close to making me reconsider: If you (the core 
developers and language designers) cannot agree on the semantics 
(stateless vs. stateful traits, etc.) I wonder how the user is going to 
feel about it.

> Traits look good. Many userland developers would use them. Many more

The use case examples I've seen so far haven't been all that convincing 
to me but that's probably because of a different coding style.

- Chris