Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43739
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.16 cause and error)
To: internals@lists.php.net
Date: Sun, 19 Apr 2009 16:28:27 -0500
User-Agent: KMail/1.11.2 (Linux/2.6.27-7-generic; KDE/4.2.2; i686; ; )
References: <e52c06b30904150713s7cb13e3ele4b075cbe803fb82@mail.gmail.com> <E98065374DA64A1D8602A3A442BF6BED@pc> <7CC5C4E4-5DBC-4B86-8F69-E786DD2BDE02@stefan-marr.de>
In-Reply-To: <7CC5C4E4-5DBC-4B86-8F69-E786DD2BDE02@stefan-marr.de>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200904191628.27472.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Grafts, Traits, horizontal reuse
From: larry@garfieldtech.com (Larry Garfield)

On Saturday 18 April 2009 12:57:19 pm Stefan Marr wrote:
> 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?

Earlier in the thread, someone suggested making properties entirely restricted 
to their trait, not any using class.  If you want access to a trait's 
property, use an accessor and be done with it.  That way it doesn't matter if 
different traits use the same property names since they'll always be resolved 
relative to the method that's using them.  Is there an implementation reason 
why that would not be a feasible solution?  From a developer experience 
perspective it seems like a reasonable approach.

Also, at the risk of scope creep I will ask if any sort of runtime knowledge 
is being considered?  That is, would there be a way to at runtime get a list 
of all traits that a given class is using, or access them separately?  Would 
that be a possible way around the question of duplicate method names?  (Vis, 
reimplement the conflicting method and then specify which of the trait methods 
you want to use by calling it, or possibly calling both of them.  That would 
allow for potentially interesting use cases, and force the resolution logic 
onto the implementer rather than trying to come up with the perfect resolution 
rules for all case.  

Eg:

trait Foo1 {
  public function foo() {}
}

trait Foo2 {
  public function foo() {}
}

class Bar {
  use Foo1, Foo2;

  public function foo() { // Without this, we get a parse error
    return $this->Foo1->foo();
    // or
    return $this->Foo2->foo();
    // or
    foreach ($this->traits as $trait) {
      $return[] = $trait->foo();
    }
    return implode(',', $return);
    // or whatever makes sense for your use case.
  }
}

-- 
Larry Garfield
larry@garfieldtech.com