Re: Revisit: Traits requiring composing class to implement interface

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: �Z/�����͐ǡ O. > 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