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