Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47617
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 85.88.12.247 cause and error)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <690D1362-7F1D-47B9-A4BF-EEA9CF38C5B0@pooteeweet.org>
Date: Thu, 25 Mar 2010 21:13:11 +0100
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <8DFD21F2-E107-4E9C-9CAD-9BDFE276F633@stefan-marr.de>
References: <690D1362-7F1D-47B9-A4BF-EEA9CF38C5B0@pooteeweet.org>
To: Lukas Kahwe Smith <mls@pooteeweet.org>
Subject: Re: [PHP-DEV] horizontal reuse: traits vs. grafts
From: php@stefan-marr.de (Stefan Marr)

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."
>=20
> 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.


>=20
> (@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.


>=20
> trait A {
>  public function smallTalk() {
>    $this->bigTalk();
>  }
>=20
>  public function bigTalk() {
>    echo 'A';
>  }=20
> }
>=20
> trait B {
>  public function smallTalk() {
>    $this->bigTalk();
>  }
>=20
>  public function bigTalk() {
>    echo 'B';
>  }=20
> }
>=20
> class Talker {
>  use A, B {
>     B::smallTalk instead A;
>     A::bigTalk instead B;
>     B::smallTalk as talk;  =20
>   }
> }
>=20
> 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.

=20


> 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

--=20
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