Grafts, Traits, horizontal reuse View as Markdown

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

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