Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42049
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain strojny.net designates 78.46.69.2 as permitted sender)
To: Christopher Vogt <christopher.vogt@rwth-aachen.de>
Cc: internals@lists.php.net
In-Reply-To: <79.C8.07308.CDE4C194@pb1.pair.com>
References: <002b01c92d67$ae92fdc0$0bb8f940$@de>
	 <79.C8.07308.CDE4C194@pb1.pair.com>
Date: Wed, 26 Nov 2008 00:06:32 +0100
Message-ID: <1227654393.4022.14.camel@localhost>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=_milch.schokokeks.org-14156-1227654395-0001-2"
Subject: Re: [PHP-DEV] Grafts, Traits, horizontal reuse
From: lars@strojny.net (Lars Strojny)

--=_milch.schokokeks.org-14156-1227654395-0001-2
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi Christopher,

thanks for (re-)starting the discussion how to make horizontal reuse
easier in PHP.

Am Donnerstag, den 13.11.2008, 16:59 +0100 schrieb Christopher Vogt:
[...]
> I had a chat with Stefan about his Traits/Grafts RFC and he suggested we
> should rather continue a discussion here.
> I really liked to see the Grafts proposal. In traits and regular
> inheritance the implementation code of several entities is somehow mixed
> and as a result one entities code can break another entities code.

To keep things fair, there were proposals to keep traits completely
stateless and to allow abstract methods in traits, so that traits can
sort of "request" the implementation of a certain method. This would
keep the inheritance chain pretty stable.

> The
> great thing about Grafts is that the implementation is not mixed. Grafts
> are completely encapsulated entities with their own state. I think in
> many cases where inheritance or traits seem tempting, complete
> encapsulation is actually the cleaner solution.

I see the point of having encapsulated state, I still wonder if it would be=
 better for us to have something simpler. Simpler, as in avoiding state at =
all. So if we had traits without state at all a) the concept is easy to exp=
lain (like "interfaces define the API, classes keep state, traits encapsula=
te implementation"). A nice and easy explainable hierarchy of responsibilit=
ies.

[... Details about grafts ...]

> However a problem remains. The methods of counter return $this (aka
> implement a fluent interface). One idea that came to my mind to solve
> this problem: PHP could provide a keyword fluent that replaces a methods
> return value to form a fluent interface i.e. return $this:
>=20
> class QueueTicketPrinter{
>   use Counter as private $counter{
>     public fluent current();
>     public fluent reset();
>   }
>   public function takeNumber(){
>     print 'your number is ".$this->counter->current();
>     $this->counter->inc();
>   }
> }
>=20
> The keyword fluent ignores whatever value the Counter function may
> return and returns an the instance of QueueTicketPrinter instead.

That's a good example why I have the feeling they are a hack. I mean a
"fluent" keyword just for a single use case. Another thing, how could I
return the class name of the current class? "public class current()".
And so on. At the end it is an issue of "late graft binding" (similar to
late static binding).

> Finally, can somebody provide a sensible use case for traits, that
> cannot be solved with Grafts? I am sure there is, but I am currently
> lacking one.

I can't think of any (except from late graft binding), however not
having anything against does not mean it is a good idea :) I still
prefer traits as they are easier to explain from my point of view, the
concept is more clear and that's the spirit that fits pretty well for
PHP.

cu, Lars

--=_milch.schokokeks.org-14156-1227654395-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Description: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)

iQIcBAABAgAGBQJJLIT3AAoJECQPF+sCY6wHIGUP/2cbazXXAF2SDUj0HEKJXQYR
rcd9LJpP+v8Dyd/dAFAF4H8QleJBCs6ue3iMsS8LZ/0B73zqonxjfXMWBF1baDUk
Y557PVrlz4hwEMcgDZBx2EBHJVFwVpByMksTSWPdwce6HYDIkWw9wiTljnMwsYYR
pUmyaRHjVz+xwgYetOZ65K9awlUiwSXUCXSrierzb0QCWpXkf+6xaZzAN5EK8m9o
hXrRXNUXplJzMumO8Qw42lI8ChdEAHfmyz/i8zp4QXOqeEiq28NgA7L9Kr//XzFC
lWIjgw+Az+zlg0b9hQmqyTITvDguSsKK79a751gb+1XvmT+4pKnwFnrLkPZtpYq1
BWbF3nAREH9pSL9zj4dbVMhE4Y/XNhGxVV31qnEvrZGVrLiPFSt7QlOmTbIV+0AM
nBDGy6TGP0sf6pD2Vock2MExcwMuHQJ7uVxgkC6lzt6iS7W9utnz4Bub9v7D16eI
6wC6mb13SXBU7tydzzwU+W44keHGA50ppXJ1tMZ/4bN0oO4PJiTy12CyUmSVaSxA
QaJNAUGK2EINXwFUcf7mSpuJrATKAEMPx/uje4pI+kD9jEPGgXj3fOovJGc68K7Y
JRh/3hwIlfnTvhnMAqt6cLjCJegnoXS58MCesPKwc10cIu38yKWiAJvmSa9XgNjk
d0bYjs8aIfzz9fd8nCbN
=rCCl
-----END PGP SIGNATURE-----

--=_milch.schokokeks.org-14156-1227654395-0001-2--