Revisit: Traits requiring composing class to implement interface View as Markdown

On Sat, Oct 22, 2011 at 8:25 AM, Anthony Ferrara ircmaxell@gmail.comwrote:

Well, I have a few opinions on this that I think are worth sharing:

Anthony, thanks for your reply.

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).

While this may be scary to many it is in fact the motivation for the
feature. Multiple inheritance or some semblance thereof is something
user-space folks have been interested in for some time [1]. There is no
unanimous interest for it, nor is there unanimous favor for practically
anything in PHP, that's what makes it unique IMO, different strokes for
different folks.

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)?

True, but doesn't the use of the abstract keyword in a trait already mean
they support specification? There may be an academic concept of a trait,
but perhaps it has already been massaged for the PHP implementation.

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?

I'm sorry I'm missing the point here, could you show a brief sample? I
think the forcing aspect is the point here though, and it is desired. A
trait that uses several methods from an interface, say Iterator or another
class like SplFileInfo. The trait should be able to say it needs a subset
of the methods in that interface or class today, and may at any time in the
future rely on any of the full set of methods defined in the interface or
class. Again, this functionality is already available in the current
implementation via the abstract keyword. It just seems silly to have to
maintain a list of methods by hand that could be done with a concise
notation instead. And it's even uglier if the trait relies on more than one
class interface, imagine code like this:

<?php
trait IteratorHelper {
/* Iterator */
abstract public function current();
abstract public function key();
abstract public function next();
abstract public function rewind();
abstract public function valid();

/* SplFileInfo */
abstract public function getATime();
abstract public function getBasename();
// etc..
}
?>

The author is wondering, do I bother to key in all the methods from
SplFileInfo now in case I ever use one of the methods I haven't in the
original implementation, or wait until I do use another method from
SplFileInfo and then update the list of abstract methods. And what if I
have an abstract method mentioned in the list, but remove calls to it from
within the trait and then forget to update the list, is that bad? Also note
the ambiguity introduced without comments indicating which foreign class /
interface these abstract (required) methods come from. The comments here,
and indeed the feature I suggest, would be more expressive to authors
because it would be explicit. Imagine encountering the code segment above
with the absence of the comments, you would be good to guess which classes /
interfaces the trait was intended to be used with. Instead something like:

<?php
trait IteratorHelper require Iterator, SplFileInfo {
//..
}
?>

is not only more concise, it is more expressive IMO in that it more clearly
indicates the author's intent for the use of said trait. It is also more
maintainable because there is no need to maintain a list of methods (for
which there is no explicit way to describe the interface / class they belong
to) when changes are made. There is also value for documentation tools.
With the current paradigm of just the abstract keywords using comments as I
suggested is not something a documentation tool can pick up, though I'm sure
it will be a matter of time until those tools cook up a silly annotation to
support 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
maximum flexibility,
we separated the properties specifying the implementation of a collection
from the
properties specifying the interface. This allowed us to freely combine
different interfaces (e.g.,
“sorted-extensible interface” and “sorted-extensible-immutable
interface”) with any of the
suitable implementations (e.g., “linked-list implementation” and
“array-based implementation”).

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...

A couple thoughts here.

1. I looked around in other language specs before re-hashing this topic and
   from what I can tell these other languages don't have a concept of
   interfaces as PHP does. One could say they do have classes proper and did
   not support traits noting the classes which they were dependent upon in
   their specification. Seems to me many of these other languages were
   more wholly conceived at their inception and I doubt the user base had been
   striving to implement multiple inheritance via a workaround for the past 5
   years. Just google 'php multiple inheritance'.

2. For better or for worse the decision to support specification within
   traits has already been made in the form of the abstract keyword. I'm
   suggesting taking it one step further for folks who are interested in some
   semblance of multiple inheritance.

If it's a nightmare to implement internally maybe it's best left alone, but
if it is straightforward I say implement it and let folks take on 'all the
problems of multiple inheritance' if they wish to; everyone else can just
laugh at them if they wish to. Isn't that the PHP way?

[1] http://www.issociate.de/board/post/478936/Multiple_Inheritance.html

thanks,

-nathan

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).

I think you misunderstand the difference between traits and mixins:
http://code.google.com/p/es-lab/wiki/Traits

Scala has mixins, php has traits.

In short, the composition order does not matter with a trait (because there are conflict resolution rules).
With a mixin, the conflict resolution rule is the order of declaration. class foo mixwith bar1, bar2 {} // bar2 wins

Though traits were originally defined as 'stateless', it doesn't make them 'mixins' because they have state:
http://bergel.eu/download/papers/Berg07e-StatefulTraits.pdf

Javascript is probably the best example of 'mixins':
myobject.mixin(bar1,bar2, {otherMethod: function(){} })

Hi Anthony:

I will not comment on the original question of this thread, but felt obliged to point out some details where my understanding differs from what I understand from your explanation.

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).

Please refer to: https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate

"Traits do not provide any provisioning for handling state."

What you observe is that PHP is a very dynamic language when it comes to the definition of fields.
And that is what traits also take into account. We do the minimal possible thing, to keep the WTF factor low, but there is no "real" support for state.
And as someone else pointed out: the main difference is indeed the difference between linear application (mixins) and order-less composition (traits).

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)?

The relevant part of the RFC: https://wiki.php.net/rfc/horizontalreuse#conflict_resolution

We abandoned the idea of an explicit exclude operator long ago. (I think it was never in the PHP SVN.)
Thus, the situation you describe cannot occur in the sense that a method is missing from the class.
However, you can of course provide incompatible method implementations. (Which does not make traits any different from any other way to implement an interface.)

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