rfc:horizontalreuse

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:horizontalreuse [2010/12/11 15:26] – Added proposal for requiring interface implementation from a composing class. gronrfc:horizontalreuse [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== Request for Comments: Horizontal Reuse for PHP ====== ====== Request for Comments: Horizontal Reuse for PHP ======
-  * Version: 2.0.1 +  * Version: 2.1.1 
-  * Date: 2008-10-12, last update 2010-11-18+  * Date: 2008-10-12, last update 2011-01-09
   * Author: Stefan Marr <php.at.stefan-marr.de>   * Author: Stefan Marr <php.at.stefan-marr.de>
-  * Status: Committed to trunk (traits only)+  * Status: Implemented in PHP 5.4 (traits only)
   * First Patch: http://www.stefan-marr.de/2009/09/traits-patch-updated-backported-and-available-on-github/   * First Patch: http://www.stefan-marr.de/2009/09/traits-patch-updated-backported-and-available-on-github/
   * First Published at: http://www.stefan-marr.de/artikel/rfc-horizontal-reuse-for-php.html   * First Published at: http://www.stefan-marr.de/artikel/rfc-horizontal-reuse-for-php.html
Line 350: Line 350:
 ==== Traits Composed from Traits ==== ==== Traits Composed from Traits ====
  
-Not explicitly mentioned jet, but implied by the flattening property is the+Not explicitly mentioned yet, but implied by the flattening property is the
 composition of Traits from Traits. composition of Traits from Traits.
 Since Traits are fully flattened away at compile time it is possible to use Since Traits are fully flattened away at compile time it is possible to use
Line 488: Line 488:
  
 ===== Visibility ===== ===== Visibility =====
- 
  
 Visibility modifiers have not been discussed so far. Since Traits are meant as Visibility modifiers have not been discussed so far. Since Traits are meant as
Line 514: Line 513:
  
 The final modifier is supported, too. The static modifier can not be used in this context. That means, a normal method can not be converted to a static method, because it would change the methods semantics and references to ''$this'' would break. The final modifier is supported, too. The static modifier can not be used in this context. That means, a normal method can not be converted to a static method, because it would change the methods semantics and references to ''$this'' would break.
 +
 +
 +===== 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 main goal being to avoid code duplication.
 +Moreover, traits should not be confused with typical use cases of classes.
 +When a strong coherence/coupling between methods and state is required,
 +and 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.
 +
 +
 +===== Reflection =====
 +
 +Status: The Reflection API is not completely adapted for traits yet.
 +
 +The following functions are added to match the existing class- or interface-specific functions. 
 +  * trait_exists()  -- returns true for traits, false for all kind of classes and interfaces
 +  * get_declared_traits()  -- returns the defined traits, no classes or interfaces
  
 ====== Grafts - Class Composition (not implemented) ====== ====== Grafts - Class Composition (not implemented) ======
rfc/horizontalreuse.1292081185.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools