Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43731
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 69.16.228.148 cause and error)
Message-ID: <FF415A8A018E4B4CADD18BA9F323FA35@pc>
To: <internals@lists.php.net>
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> <7CC5C4E4-5DBC-4B86-8F69-E786DD2BDE02@stefan-marr.de>
Date: Sat, 18 Apr 2009 21:19:31 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Grafts, Traits, horizontal reuse
From: sv_forums@fmethod.com ("Stan Vassilev | FM")

> 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

Hi,

Since the expectancy of a trait is it'll be used in many other classes 
horizontally, I wouldn't think people will start taking generic names in 
traits as they do in normal classes.
I'd personally expect this naming convention more likely:

trait Counter { protected $counterValue; }
trait Observable { protected $observableListeners; }

And so on. The benefit is it's easy to implement, understand, and use.

However if this is not acceptable to many, and we could live with the 
complication of it, the best idea for trait property access I suppose would 
be this:

trait Observable {
    protected $listeners;
}

class Any {
    use Observable;

    function accessTraitProperty() {
        var_dump($this->Observable->listeners);
    }
}

Hence namespacing trait state into an automatically created object of the 
same name, and we're done.

On the other said, a all traits could have an automatic property "owner", 
which gives it access to the class state/properties.

Regards,
Stan Vassilev