Timeline for Lvl2 upgradeable attributes
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 27, 2015 at 10:50 | vote | accept | Nick Udell | ||
| Jan 22, 2015 at 22:22 | comment | added | apieceoffruit | @BenAaronson I see your point and it can be as well but there is a very special reason i did it this way. an attribute ahs a base value, so conceivably in a game context certain situations might call for performing a calculation off the base value. Well, a modifier alters the effects ON the attribute but in some cases you dont want to superceed that, effectively the Decorator version is a code contract to ensure valid values while a modifier version is a calculatory clamp. different uses. In the same way I'd create a notifyAttribute that implements notifypropertychanged, not as a modifier | |
| Jan 22, 2015 at 17:32 | comment | added | Ben Aaronson |
I'd argue the clamping should be done as an IModifier, rather than an IAttribute decorator.
|
|
| Jan 22, 2015 at 17:18 | comment | added | Nick Udell |
I love your point about swapping to just IModifier instead of an internal collection and letting the dependency manage itself. That will really improve fluency and flexibility!
|
|
| Jan 22, 2015 at 17:15 | history | answered | apieceoffruit | CC BY-SA 3.0 |