Can Enumeration.options.beforeFreeze be eliminated?

[samreid]

From #50, we now have rich enumerations. Can we use that instead of beforeFreeze and delete beforeFreeze?

[samreid]

It looks like occurrences of beforeFreeze dealing with enumeration values can be replaced with Enumeration.byMap values. However, several occurrences are assigning static enumeration methods like MyEnumeration.staticMethod(...) using beforeFreeze. I wonder if there is a better way for doing this. Perhaps subtyping Enumeration and adding static methods would work? Or maybe the Enumeration shouldn`t be frozen and we can set static attributes on it the way we used to?

@jonathanolson what do you recommend?

UPDATE: What about freezing KEYS and VALUES but not the Enumeration instance itself?

[jonathanolson]

Subtyping Enumeration sounds like something we'd do for a different class of enumerations, we really want to add methods to a single Enumeration object. I guess the freeze is to make sure we don't overwrite object values... maybe we could add a way of adding static information in another way? (An options object that gets extended into the enumeration object itself? A method addStatic or something that we can add methods/values with, e.g. SomeEnumeration.addStatic( 'getSomething', () => 5 )`)

Ideally we want to prevent SomeEnumeration.SOME_VALUE = 5 (which the freeze on the Enumeration itself provides), but we want to allow the equivalent of SomeEnumeration.someMethod = ...

[samreid]

I don't have any plans to work on this in the near future. Unassigning.