On 01 Aug 2012, at 16:31, Stan Vass wrote: >> Because it is not a matter of horizontal reuse. >> Why don't you get a warning when you override an inherited method? >> Because that is precisely the way things are supposed to work. >> >> The body of a class is not a trait. These methods are not 'equals'. >> I still think that design decision is a sensible one with respect to the >> rest of PHP. > > If traits act like superclasses, why can the class call a private trait > method, by that logic?
Traits have a very simple semantics: Step 1: identify which traits are to be used. Step 2: resolve conflicts between traits. Step 3: flatten the result into the class. Step 4: do in the class what ever you are used to do in a normal class. This results in a "Glorified copy-and-paste.". This explains why traits are allowed to access private methods, because they are part of the class. They are flattened into it. But, they are flattened into the class before the body of the class is processed. > So what is it? It's neither and both. I expect a mighty confusion and abuse > of traits because they can't decide what they are in 5.4. Traits should pick > one model and stick to it. Yes, I agree with you that there are known problems with state. To quote myself: https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate "Traits do not provide any provisioning for handling state. They are meant to provide a light-weight mechanism for flexible code reuse, with the main goal being to avoid code duplication." Property support is a best-effort solution at the moment. Following the rules outlined in the RFC: " • Properties are considered incompatible if they differ in their definition. This means, they differ in the applied modifiers (static, public, protected, private) or their initial value. • Incompatible properties result in a fatal error. • In all other cases, i.e., when the definitions are identical, an E_STRICT notice is shown to raise awareness about the potentially problematic, and discouraged use of properties. • For those checks, all properties are treated equal. Properties from the base class and the composing class have to be compatible with properties from traits as well as the properties between all traits have to be compatible. • Non-coliding properties, and properties which are not considered incompatible behave exactly the same as if they would have been defined in the composing class. " Please provide a fix in form of an RFC and a patch. Thank you! > My proposal is what I said above. Either aliases should be *dropped* as a > feature from traits and the feature has to be rethought, or they have to work > sensibly as outlined in 1) and 2) above. > > IMO they do more harm than help in their current form. Sometimes not > implementing a compromise is a feature itself. I disagree with the premise that renaming is necessary. >> http://scg.unibe.ch/archive/papers/Berg07aStatefulTraits.pdf > > Let me quote that PDF you've linked me to: > > "By default, variables are private to the trait that defines them. Because > variables are private, CONFLICTS BETWEEN VARIABLES CANNOT OCCUR when traits > are composed. If, for example, traits T1 and T2 each define a variable x, then > the composition of T1 + T2 does not yield a variable conflict. Variables are > only visible to the trait that defines them" > > "By default, instance variables are private to their trait. If the scope of > variables is not broadened at composition time using the variable access > operator, CONFLICTS DO NOT OCCUR AND THE TRAITS DO NOT SHARE STATE." > > Emphasis mine. > > This is absolutely not what is implemented in 5.4, and this is in part why > we're having this thread now. You are missing the point of the complexity that comes with the whole proposal. Granting access, and merging add quite some complexity to the language (not only the implementation). There have been proposal like a 'local' keyword for traits before. They never got implemented. > My point which I've described multiple times at this point is that traits are > not classes, we already have classes in PHP, you know? Imitiating classes > with traits is the wrong mental model for their behavior, and the paper > you're linking me to confirms tht. How do you prevent a user from using dynamic (properties that are not predeclared) in a method that comes from a trait? >> There is nothing simple in PHP... >> People don't like fatal errors, especially not for things they intend to >> just work. >> From my example above, the kind of guarantees you expect are just not >> something that is part of what PHP is. > > Letting conflicts overwrite randomly properties is not "just working". It's > an example of "not working, and it's very hard to debug why." Again, what is your point? PHP is the wrong language for you then. PHP is very dynamic and let's you shoot yourself in foot in all kind of strange ways. Traits do not change these semantics. They try to integrate with them. And the main problem here is that PHP got dynamic properties. If you want to change the semantics to 'local-to-trait'-by-default fields, please provide a patch and an RFC. I won't stop you. On the contrary, it is certainly an appealing option. Throwing a FATAL however is not an appealing option. We are already pretty strict when we see that it is most likely a bug. And we give you a E_STRICT warning. That's what we can do for the moment. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
