Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43730
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)
To: Stan Vassilev | FM <sv_forums@fmethod.com>
In-Reply-To: <E98065374DA64A1D8602A3A442BF6BED@pc>
References: <e52c06b30904150713s7cb13e3ele4b075cbe803fb82@mail.gmail.com> <52F25C37-F12D-4A85-A7D3-C579637B56C5@stefan-marr.de> <e52c06b30904171020r390a042ar42582acf9ca7b082@mail.gmail.com> <3B04560F-97DC-423D-8606-3436F28EF2D1@stefan-marr.de> <E98065374DA64A1D8602A3A442BF6BED@pc>
Message-ID: <7CC5C4E4-5DBC-4B86-8F69-E786DD2BDE02@stefan-marr.de>
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: Sat, 18 Apr 2009 19:57:19 +0200
Cc:  <internals@lists.php.net>
Subject: Re: [PHP-DEV] Grafts, Traits, horizontal reuse
From: php@stefan-marr.de (Stefan Marr)

Hi Stan,

> I see this in a much simpler fashion. Treat traits as a preprocessor  
> step semantically.
>
> Internally, trait methods on multiple classes may point to the same  
> method to save resources, but in my opinion there's no need to  
> complicate matter by introducing new resolution rules, scopes, and  
> so on.
> The way I see it:
>
> 1) Property/Method name conflicts on trait/class, within the class  
> including the trait raises Fatal Error.
Well, with methods this is ok, but properties are not Java fields  
which are known at compile time, so it is not that easy. Even when  
they are known beforehand things are more complicated.

State is usually even less composable than behavior/methods.

> 3) There's a single space for a class property and its trait  
> properties, so access works as if it was all class properties.

trait Counter {
   var $value;
   public function inc() { $this->value++; }
   ...
}

trait Color {
   var $hue;
   var $saturation;
   var $value;
   public function getRGB() { /* ... */}
   ...
}

class MyClass {
   use Counter, Color;
}

Ok, you could argue that you than will have to refactor your property  
names in your state. But then you will break other traits. Even worth,  
this trait is defined in a widely used framework and your breaking  
other peoples code just by changing implementation details which  
should not even be visible to your users.

I do not think that this simple model is practicable. Unfortunately,  
it is implied by the current state-less proposal, if we do not forbid  
any access to properties inside of trait methods (which sounds like a  
stupid idea to me). :(

Regards
Stefan

>
>
> Feedback?
>
> Regards,
> Stan Vassilev
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

-- 
Stefan Marr
Programming Technology Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://prog.vub.ac.be/~smarr