horizontal reuse: traits vs. grafts

Ahoi,

Thought it would be better to open up a new thread and also using the
term "horizontal reuse" in the subject so that we make it clearer that
there are actually two approaches. Here is the URL for Stefan's
proposal:
http://wiki.php.net/rfc/horizontalreuse

One thing I feel is missing from the RFC is how is_a() and instanceof are
affected with traits or grafts.

From:
http://github.com/gron/php-src/blob/PHP_5_3-traits/Zend/tests/traits/languag
e009.phpt

class Foo {
use C, A, B {
B::foo instead A, C;
}
}

$f = new Foo;

echo is_a($f, 'A'); ?
echo is_a($f, 'B'); ?

It's seem to me that a defining a 'trait' should be advertised strictly as
an 'advanced multiple inheritance technique' to reuse pieces of code and it
shouldn't be considered as an object (grafts proposal).

I don't like the "B::foo instead A, C" stuff though, so I agree with Lukas
and find that Grafts are more intuitive / easy to learn.

Personally, this syntax makes me happy but would keep the 'use' or 'with'
keyword:
http://wiki.php.net/rfc/nonbreakabletraits

trait A {
protected function foo() {
echo 'a';
}
}

trait D {
public function foo() { echo "d"; }
function bar() { echo "d"; }
}

class Foo {
use A;
use D {
function bar();
}
}

$f = new Foo;

echo is_a($f, 'A'); // true
echo is_a($f, 'D'); // false, since we've done an explicit
selection/brackets: use D {}

This is mainly userland feedback

The third sentence is not so clear to me, but if I guess it its also
just a typo as it makes more sense to me when replacing "renaming" to
"result in renaming". But maybe you could tweak that paragraph to be a
bit clearer. For example its still not totally clear to me why
aliasing doesn't imply inclusion, I guess its definitely more
flexible.

It was really unclear to me too, this example cleared it up:

http://github.com/gron/php-src/blob/PHP_5_3-traits/Zend/tests/traits/bugs/al
ias-semantics.phpt

The current trait implementation does not 'rename' the previous method but
creates an 'alias'.

class Talker {
use A, B {
B::smallTalk instead A;
A::bigTalk instead B;
B::smallTalk as talk;
}
}

I think in this case, it would output 'A'.

Personally I would prefer to see:

class Talker {
use A {
public function bigTalk();
}
use B {
public function smallTalk();
public function smallTalk() as talk(); // this 'renames' the function /
not an alias
}
}

Other example:

class Talker {
use A;
use B {
public function smallTalk() as talk();
}
}

Hi,

"In case of the above definition of Talker, PHP will show a warning that there have been conflicts and name the methods smallTalk() and bigTalk() as the reason of this conflict. Therefore, neither of the given implementations will be available in the class."

I think this is a fundamental decision, should it be a warning or a fatal error? Generally I prefer PHP to keep on going whenever it can. I guess in most cases if we stick to a warning the user will end up with a fatal error anyway, but it might not be so clear why the given method is unavailable. But there should still be a warning, which I guess cannot be suppressed all that easily.
Well, I do not like a fatal errors. This problem does not leave the engine in an undefined state, and personally, I think, fatals should only be caused by something which really cannot be handled.

Since we have __call, there might even be something executable.

(@Stefan: didnt want to start editing minor typo's in the RFC .. s/waring/warning .. that typo can be found in other places too)
Thanks, fixed that.

"The introduction of a new name is not renaming and references in methods to a given method name aren't changed either."

The third sentence is not so clear to me, but if I guess it its also just a typo as it makes more sense to me when replacing "renaming" to "result in renaming". But maybe you could tweak that paragraph to be a bit clearer. For example its still not totally clear to me why aliasing doesn't imply inclusion, I guess its definitely more flexible. How will things work when traits have overlapping method names when other methods of the given traits call these overlapping methods?
I have not changed that paragraph, but I added a discussion section about renaming, and linked to it.

trait A {
public function smallTalk() {
$this->bigTalk();
}

public function bigTalk() {
echo 'A';
}
}

trait B {
public function smallTalk() {
$this->bigTalk();
}

public function bigTalk() {
echo 'B';
}
}

class Talker {
use A, B {
B::smallTalk instead A;
A::bigTalk instead B;
B::smallTalk as talk;
}
}

What is there anyway to ensure that when Talker::talk() is called that B::bigTalk() is still called and not A::bigTalk() because I want to maintain the "integrity" of each trait? Is that what you mean with its "not renaming and references in methods to a given method name aren't changed either" as in it will indeed call B::bigTalk()? Reading further long I however see that "This leads to missing features like recursion for methods introduced by aliases." Also I guess exactly this is the key difference to Grafts.
Yes, that is the key difference.
Traits are meant to be light-weight and composeable. This includes, that I see it as a feature, that Traits can call methods of other Traits.

Reading further about Grafts, I must say I really like that approach. I mean we have talked about traits for quite a bit already, but I feel like I got how Grafts work the first time reading. I also like the fact that since Grafts are just classes, people can integrate them as they see fit, like they can use delegation if they are still on an older version of PHP or use Grafts. I also envision that there will be less surprises when using Grafts and this fits well with the approach to keeping the barrier to entry low for PHP development.
Well, how do we reach a conclusion on that whole topic?

With a poll?

Best regards
Stefan

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525