rfc:horizontalreuse
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
rfc:horizontalreuse [2011/04/06 10:59] – external edit 127.0.0.1 | rfc:horizontalreuse [2013/10/29 17:24] – -> Implemented nikic | ||
---|---|---|---|
Line 3: | Line 3: | ||
* Date: 2008-10-12, last update 2011-01-09 | * Date: 2008-10-12, last update 2011-01-09 | ||
* Author: Stefan Marr < | * Author: Stefan Marr < | ||
- | * Status: | + | * Status: |
* First Patch: http:// | * First Patch: http:// | ||
* First Published at: http:// | * First Published at: http:// | ||
Line 350: | Line 350: | ||
==== Traits Composed from Traits ==== | ==== Traits Composed from Traits ==== | ||
- | Not explicitly mentioned | + | Not explicitly mentioned |
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 519: | Line 519: | ||
Traits do not provide any provisioning for handling state. | Traits do not provide any provisioning for handling state. | ||
They are meant to provide a light-weight mechanism for flexible code reuse, | They are meant to provide a light-weight mechanism for flexible code reuse, | ||
- | with the mean goal being to avoid code duplication. | + | with the main goal being to avoid code duplication. |
- | Moreover, should not be confused with typical use cases of classes. | + | Moreover, |
When a strong coherence/ | When a strong coherence/ | ||
- | and certain | + | 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 | indication that a class is the right abstraction to implement that problem | ||
with. | with. |
rfc/horizontalreuse.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1