Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55898
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL5nwZ6RF8Z3FV1vKgxoFZoBJiRp_qBNSx5MXAe_8-jbmj5OOA@mail.gmail.com>
References: <CAL5nwZ6RF8Z3FV1vKgxoFZoBJiRp_qBNSx5MXAe_8-jbmj5OOA@mail.gmail.com>
Date: Sat, 22 Oct 2011 10:25:54 -0400
Message-ID: <CAAyV7nGK20r22e8TyquypLSn2irMHsoG6oK9vG7ge40WgYk1Ww@mail.gmail.com>
To: Nathan Nobbe <quickshiftin@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Revisit: Traits requiring composing class to implement interface
From: ircmaxell@gmail.com (Anthony Ferrara)

Well, I have a few opinions on this that I think are worth sharing:

1. If this change is made, we no longer would have mixins, but would
have regular multiple-inheritance (With all the "issues" associated
with it).  Note that I said mixins and not traits.  That's because
since these were implemented with state (member properties), they are
not traits as implemented, but regular mixins. (Yet another gripe, but
that's slightly off topic).

2. Traits and mixins are supposed to be the symmetric counterpart to
interfaces.  An interface is a specification without implementation.
A trait/mixin is supposed to be implementation without specification.
And a class (including abstract) is implementation with specification.
 So if you allowed type hinting of traits/mixins, wouldn't that just
make them nothing more than abstract classes (in that they can't be
used directly, but both provide the same info)?

There's a much bigger problem though.  How would you solve the problem
where a class uses a trait that implements an interface, but you don't
pull one of the methods through (for example, you exclude it in the
use clause)?  At first this sounds simple, just enforce it on the
class.  But that means that the compiler couldn't enforce the
interface at definition time of the trait.  So then that means that by
the trait implementing the interface is actually *forcing* any class
that implements it to be compliant and ensure that it implements the
interface.  So at that point the trait stops being useful for
horizontal reuse, but becomes nothing more than a class with the
limitations that brings along.  Traits/mixins were designed to avoid
this problem.  So why should we re-introduce it?

Some of that is design choice, but I think we need to realize that
there are a lot of people who have thought about these problems before
in other areas of CS.  What do other languages do?  Can you name one
mainstream language that implements traits/mixins as a first class
citizen where they can implement an interface or can be type-hinted
against?  In fact, the original paper the RFC references
(http://scg.unibe.ch/archive/papers/Duca06bTOPLASTraits.pdf)
explicitly recommends separating the specification (interface) from
the trait:

A quote from that paper:

> We solved these problems by creating traits for the different collection =
properties and
> combining them to build the required collection classes. To achieve maxim=
um =EF=AC=82exibility,
> we separated the properties specifying the implementation of a collection=
 from the
> properties specifying the interface. This allowed us to freely combine di=
fferent interfaces (e.g.,
> =E2=80=9Csorted-extensible interface=E2=80=9D and =E2=80=9Csorted-extensi=
ble-immutable interface=E2=80=9D) with any of the
> suitable implementations (e.g., =E2=80=9Clinked-list implementation=E2=80=
=9D and =E2=80=9Carray-based implementation=E2=80=9D).

So in all, I feel it would be a significant mistake to allow traits
(mixins) to implement interfaces or be type-hinted against.  It goes
against the principles that they were designed with and destroys some
of their key benefits...

Anthony

On Sat, Oct 22, 2011 at 4:38 AM, Nathan Nobbe <quickshiftin@gmail.com> wrot=
e:
> Hi folks,
>
> With a 5.4 release right around the corner I'd like a moment of your time=
 to
> reconsider this issue [1].
>
> I've read through the original conversation [2] and would summarize the
> points as follows:
>
> . several folks see value in the feature
> . the feature would not be an impedance for people who did not wish to us=
e
> it
> . there was only one objection which was largely subdued
>
> The common use case of pairing traits with interfaces is the case where t=
he
> feature adds value.
>
> Just curious why it died on the table if several folks saw value in it,
> including Stephan who I gather is the primary architect of traits.
>
> The dispute regarding the feature was the merit of a 'compile time' check=
 vs
> placing the burden on the developer to ensure all methods in a trait are
> provided by the class in which it is used. =C2=A0In an earlier conversati=
on about
> traits Stefan said this:
>
> "Yes, Traits are meant to be compile-time only, they are not used to
> introduce typing relationships."
>
> Which makes me even more comfortable about the merit of another compile t=
ime
> check. =C2=A0As I argued in the original thread, the feature is merely an
> embellishment atop the already supported use of the 'abstract' keyword as=
 it
> pertains to traits. =C2=A0And what if nothing else are features like PPP,
> abstract, interfaces etc than syntactic sugar? =C2=A0Plus it will save fo=
lks some
> typing :)
>
> [1]
> https://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_imp=
lement_interface
> [2] http://marc.info/?l=3Dphp-internals&m=3D129188077704898
>
> thanks,
>
> -nathan
>