Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56344
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 81.20.134.149 cause and error)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <CADqTB_j743b3t-Od=URRcCORcNpTx0EEuNcwR=m4VQE6mKu7+A@mail.gmail.com>
Date: Wed, 16 Nov 2011 13:09:13 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <D3AE39BE-CE3D-46DB-B3D0-80620C63FBF2@stefan-marr.de>
References: <CADqTB_gFghdGkB4EUFOusuX5r-UW0A2k9yHjh=Sn3_Un0sn2ZA@mail.gmail.com> <F0E9EA86-C4A6-4AFA-B94F-DE6CCDA143F2@stefan-marr.de> <CADqTB_j743b3t-Od=URRcCORcNpTx0EEuNcwR=m4VQE6mKu7+A@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Subject: Re: [PHP-DEV] some notes about traits
From: php@stefan-marr.de (Stefan Marr)

Hi Rasmus:

On 16 Nov 2011, at 01:17, Rasmus Schultz wrote:

> I knew about the traits features in Scala, and I guess I assumed this =
would
> be similar - not so.

Right, they are not the same. PHP's traits are much closer to the notion
of traits introduced in the Smalltalk world, while Scala's traits are =
rather like
mixins as for instance in Ruby. Aside issues like typing and whether =
that type
information is preserved, the main difference is that PHP's traits do =
not use
implicit conflict resolution.


> I believe the key to understanding traits, is understanding that =
traits are
> in fact an implementation detail - an artifact that does not really =
change
> or affect the nature of OOP in PHP as such, and by design, should not. =
I
> understand that now - thank you :-)
>=20
> =46rom my perspective, a key difference from classes and interfaces, =
is that
> traits have no meaningful use at run-time - no type-hinting and with =
no
> real reflection-features that reveal the details. They cannot =
implement
> interfaces for classes, but classes can use them to implement =
interfaces.
> Traits just provide a set of method implementations that can be =
aggregated
> by classes. So in a sense, they're a design-time tool for the =
programmer.
>=20

I like that explanation, thanks!


> So I guess my remaining quibble is that the documentation needs to =
relay
> this somehow - with a basic real-world example that actually uses an
> interface too, to clarify the difference, and to demonstrate how this =
tool
> use useful in conjunction with class and interface declarations. Hello
> world really doesn't explain anything, other than the syntax.

[...]

> This may be a little too magical for an example in the documentation =
though
> - and doesn't demonstrate interfaces.
>=20
> I'll ponder this and post a better example if I can think of one... =
:-)

As someone else already pointed out, there are tools to contribute such =
nuggets to the documentation. Please submit a patch.


> And just one other comment:
>=20
>>> var_dump($test instanceof CartBehavior); // =3D> false
>=20
>> Why would it be beneficial to throw an exception here?
>=20
> CartBehavior is a trait, and not a class or interface. The instanceof
> operator has no meaning for traits - it always returns false.
>=20
> You could argue that false is the expected result - I would argue that =
the
> only reason this happens to work at all, is because traits internally =
are
> classes.
>=20
> Suppose you thought you were actually doing a meaningful type-check of =
some
> sort? If by mistake you put a trait-name where you meant to put the =
name of
> an interface or class, such an error could be very hard to spot.

While I agree that it can be hard to spot, I would usually advocate for =
less
intrusive alternatives.

Hmmm, well, I could put in a warning in strict mode, I guess.
But that would require a consistent handling within all the other APIs =
we got, too.
Especially is_a is such a candidate. And changing is_a seems to be a =
non-trivial
thing. So, I will need to look carefully at that.

Would be great if you could file a bug report for that.

> I hope this feedback is useful :-)
Yes it is. I think it is especially important that other people actually =
write down their understanding of the mechanism. Blog posts, mailing =
list posts, improved documentation,
they are all important.

Thanks
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