←Older revision |
Revision as of 18:40, 12 February 2010 |
Line 668: |
Line 668: |
| to Move. Feel free to remove this comment, if not appripriate. | | to Move. Feel free to remove this comment, if not appripriate. |
| --[[User:JaroslavTulach|JaroslavTulach]] 05:21, 10 February 2010 (UTC) | | --[[User:JaroslavTulach|JaroslavTulach]] 05:21, 10 February 2010 (UTC) |
| + | |
| + | My own design paradigm regarding the Enum class is NOT to put additional |
| + | behavior into the Enum, which would reduce it's flexibility and applicability |
| + | in other contexts. I use the paradigm of array indexing via the Enum ordinal |
| + | to allow for unlimited future behavior without needing to re-open the Enum class |
| + | to add more code. Re-opening the Enum class exposes vulnerability to backward |
| + | incompatibility. The Enum class simply associates a number to a semantic meaning. |
| + | The behavior for each Enum member is always provided elsewhere, and there is no |
| + | limit to the number of new behaviors that can be defined without breaking the |
| + | backward compatibility. I understand that there are situations where the designer |
| + | knows with absolute certainty that there will be no future extensions to the |
| + | behavior required of the Enum class, and so it is safe to put that behavior |
| + | directly into the Enum class. I think those situations are the rarity, rather |
| + | than the normal case. |
| + | Jeffrey D. Smith |
| + | --[[Special:Contributions/66.47.27.36|66.47.27.36]] 18:40, 12 February 2010 (UTC) |
| | | |
| At this point, most of the LinkListClosure is implemented in a | | At this point, most of the LinkListClosure is implemented in a |