| ←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 |