Hi,
On 24 Mar 2010, at 11:50, Lukas Kahwe Smith wrote:
> "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