Re: Revisit: Traits requiring composing class to implement interface

Hi Anthony: On 24 Oct 2011, at 07:06, Anthony Ferrara wrote: >> 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. Please read the RFC. Thanks! "Traits do not provide any provisioning for handling state." "However, every behavior needs state to operate on, otherwise it could be just a static functional helper method. Thus, trait code will either need to use accessors, which is favorite way to go since it provides full traits semantics, or they use properties, which is possible but rather a convenience feature." "Thus, the goal for a consistent language design is to raise awareness of the problem, promote the use of accessors, and break early in case the changes to a trait is potentially problematic for a class using it. This results in the following rules: [...]" This is purely a matter of consistence with the dynamic nature of PHP. We allow explicit naming of the properties, and that is all. There is no handling of any semantics, there is no conflict resolution, there is no state merging, splitting or what ever you would need to have a powerful enough semantics for stateful traits. Thus, I maintain the position that our traits do not provide any handling for state. However, they break early when a conflict/incompatibility is assumed. That is all, nothing more. > Traits can explicitly define properties which actually > prevent the parent class from changing this. What is a parent class with regard to a trait? That concept does not exist. > See these two examples: > http://codepad.viper-7.com/fqD91I and > http://codepad.viper-7.com/DFDpqM That is not a parent class, that is a using class or user, not a parent. > 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. As I outlined above, I disagree with that position. It does not mean that traits handle/have state! That only means that we cater for the nature of PHP. Perhaps the difference is academic, but it is quite important for me. We cannot do without that breaking early property, because being conservative here seems the best option we have at the moment. Bailing out in case of possible conflicts is the only way to avoid subtle bugs. But the semantics of the properties are exactly as if they are defined in the class, which means that there is no notion of state what so ever associate with the trait. It is only realized in the final class, and the corresponding object. The trait merely declares it. > >> 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). I think, I do not understand what you are getting at. The problem that cannot occur is that you get a runtime error because a method is completely missing from a class. You can neither exclude nor rename a method. We do not have exclude, and we only got aliasing. Neither of these mechanisms will lead to a case where a method is completely missing from the eventual class. > Implementation without any contract. Yes. 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