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
la...@garfieldtech.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
