Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55917
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <7403D757-228F-4C59-BCE5-8731BEC5CA25@stefan-marr.de>
References: <CAL5nwZ6RF8Z3FV1vKgxoFZoBJiRp_qBNSx5MXAe_8-jbmj5OOA@mail.gmail.com>
	<CAAyV7nGK20r22e8TyquypLSn2irMHsoG6oK9vG7ge40WgYk1Ww@mail.gmail.com>
	<7403D757-228F-4C59-BCE5-8731BEC5CA25@stefan-marr.de>
Date: Mon, 24 Oct 2011 10:06:13 -0400
Message-ID: <CAAyV7nEP=FLx7+=CnoV7HHDvmkD3pgOcjaHg1qvpGEp_Q6d_Gg@mail.gmail.com>
To: Stefan Marr <php@stefan-marr.de>
Cc: Nathan Nobbe <quickshiftin@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Revisit: Traits requiring composing class to implement interface
From: ircmaxell@gmail.com (Anthony Ferrara)

Stefan,

Thanks for the reply.  I disagree on a few points that you made
however.  See below for my reply.

> Please refer to: https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate
>
> "Traits do not provide any provisioning for handling state."

The original RFC was correct in that traits should not have any state.
 However the implementation differs from the RFC significantly in that
respect.

>
> 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).

Incorrect.  Traits can explicitly define properties which actually
prevent the parent class from changing this.  See these two examples:
http://codepad.viper-7.com/fqD91I and
http://codepad.viper-7.com/DFDpqM  So there is absolutely 100% support
for state here.  I could understand if it was a dynamic property or
the like, but this is really state.

> 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.)

The situation can absolutely happen simply with the conflict
resolution (as you say).  In fact, that way is worse since the
signatures are different it means that you literally cannot use both
traits (with the situation I originally described, all it would take
is implementing a dummy method to complete the interface).

As I said before, traits are supposed to be the symmetric dual to
interfaces.  Implementation without any contract.  If we take a look
at the following table, you can see that one corner is currently
empty.  And that corner is the one that's supposed to be filled by
traits.  If we allow traits to "implement" an interface, that corner
remains empty...

______________|_Implementation_|_Contract
Implementation_| Interface_______|_Class
Contract_______| Class_________|_???????

Again, just my $0.02...

Anthony