You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There doesn't really seem to be much gained from wrapping everything in a class, but perhaps I'm missing something? For one it's not possible to forward declare the enum any longer since it's nested. If you try to retrofit it into an existing code base you run into a myriad of problems because suddenly your enums aren't really enums any longer. Enums are strongly typed from the get go, so it would seem most if not all the functionality could be had from generating function overloads anyway?
The text was updated successfully, but these errors were encountered:
Some of the trade-offs are listed in Should Better Enums provide enum "objects" or traits types? in the design decisions FAQ. There is also a link to an old implementation of Better Enums-as-language-enums. However, at the time I was publishing this repo, I chose not to go with the language-enums-plus-functions approach for the reasons described in the FAQ, and I haven't yet had the time and a strong enough reason to revisit that in this repo.
There doesn't really seem to be much gained from wrapping everything in a class, but perhaps I'm missing something? For one it's not possible to forward declare the enum any longer since it's nested. If you try to retrofit it into an existing code base you run into a myriad of problems because suddenly your enums aren't really enums any longer. Enums are strongly typed from the get go, so it would seem most if not all the functionality could be had from generating function overloads anyway?
The text was updated successfully, but these errors were encountered: