Hi Larry: On 20 Dec 2010, at 17:04, la...@garfieldtech.com wrote: > Perhaps if both traits use the same variable name, visibility, *and* default > value then there is no error? There is not fatal error, however, currently there is E_STRICT notice.
> I suspect this issue dovetails with the Traits-and-interfaces thread from > earlier. Ehm, not sure what you want to get at. The idea of expressing that the composing class needs to satisfy an interface, or perhaps inherit from a specific class still seems to have a number of valid use cases. However, there was a single strong opinion against it, as far as I remember. Anyway, on the topic of properties. For the records, I updated the RFC with the following section. http://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate Comments are welcome. Thanks Stefan ===== Handling of Properties/State ===== Traits do not provide any provisioning for handling state. They are meant to provide a light-weight mechanism for flexible code reuse, with the mean goal being to avoid code duplication. Moreover, should not be confused with typical use cases of classes. When a strong coherence/coupling between methods and state is required, and certain invariants have to be maintained on the state, this is a good indication that a class is the right abstraction to implement that problem with. 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. Since state is a complex problem, and the knowledge about compatibility of state form different traits is only present in a concrete composition, proper state handling would need language features which are currently considered beyond the scope of what is necessary for PHP. (See [[http://scg.unibe.ch/archive/papers/Berg07eStatefulTraits.pdf|Bergel et al]]) 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: - 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. This property handling was implemented in [[http://svn.php.net/viewvc?view=revision&revision=306476|SVN revision 306476]] and examples are given in the test cases. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- 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
