Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43725
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 85.88.12.247 cause and error)
Cc: internals@lists.php.net
Message-ID: <52F25C37-F12D-4A85-A7D3-C579637B56C5@stefan-marr.de>
To: Tom Boutell <tom@punkave.com>
In-Reply-To: <e52c06b30904150713s7cb13e3ele4b075cbe803fb82@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 17 Apr 2009 16:16:05 +0200
References: <e52c06b30904150713s7cb13e3ele4b075cbe803fb82@mail.gmail.com>
Subject: Re: [PHP-DEV] Grafts, Traits, horizontal reuse
From: php@stefan-marr.de (Stefan Marr)

Hi Tom,


On 15 Apr 2009, at 16:13, Tom Boutell wrote:
> PHP needs "real" horizontal reuse, no question.
Looking forward to get this discussion running once again after 5.3 is  
released :)

> My first reaction to traits was positive - it's simple and simple is  
> good.
> However I'm very concerned about the implications of not allowing  
> state.
> In the real world people are going to want to do horizontal reuse that
> involves state. So they will work around it.

I share you're concerns about state.

Even though, I would like to keep Traits as simple as possible.
 From my perspective, it would be possible to introduce a full-grained  
language concept for traits like proposed in the literature [1]. But,  
it is quite complex.
On the other hand, this language constructs would be only used rarely,  
and in this rare situations, it would be probably beneficial to have  
them at hand. Merging attributes/properties of traits, aliasing and so  
on.

For the sake of simplicity, we might discuss a very basic solution.
It would be possible to introduce trait-local state only.
Thus, all properties defined in a trait are only available within  
methods of the same trait, no other operations are able to access  
these properties.

How ever, there are also corner cases. (Behavior might be different in  
case of name clashes for dynamically created properties within a  
composition, changing behavior depending on the order of method  
invocations on a single object)


> My feeling is that traits should permit state and allow the renaming
> of member variables just as they allow the renaming of methods.
Just to be clear, there is no such thing like renaming. Renaming is  
just not possible with a dynamic language like PHP. ($this->$bar =  
'baz'; $this->$foo();... )

Best regards
Stefan


[1] http://www.iam.unibe.ch/~scg/Archive/Papers/Berg07eStatefulTraits.pdf


-- 
Stefan Marr
Programming Technology Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://prog.vub.ac.be/~smarr