I wish enum was never part of TypeScript. It’s this one odd thing unlike the rest.
Am I forgetting any or is it the only feature that actually generates code rather than just being extra annotation?
Am I forgetting any or is it the only feature that actually generates code rather than just being extra annotation?
`const enums` (beyond enums) are especially odd. They rely on type information to emit code.
* Subsequent to their release in TypeScript, EcmaScript versions now support some of these.
Moreover, aside from namespaces and enums (which are discouraged), none of those features were incorporated into TypeScript until they were on track for inclusion into JS. They weren't taken from TypeScript and imported into JS; TypeScript took them from the ECMAScript people.
Being able to compile TypeScript by just stripping types has become a design principle of the language. For better or for worse, the TypeScript team steadfastly refuses to try to innovate on runtime language features at this point.
> For better or for worse, the TypeScript team steadfastly refuses to try to innovate on runtime language features at this point.
Yes, largely because ECMAScript has advanced so far relatively to where it used to be.
The problem with using strings is that nothing else uses strings (like say, your database), so you have to have this interminable roundtrip conversion between strings and integers.
JS programmers are in a bit of a bubble where using strings as enums is socially acceptable, if a C programmer saw this code
typedef struct {
const char* type;
} Animal;
If a database engineer saw this schema:
CREATE TABLE animal (
id INTEGER PRIMARY KEY,
type TEXT
)
It's way nicer to use integer enums from A to Z, because everything else has enums and people use them.
If you use plain integers instead of integer enums then the compiler has no visibility into what your tags are. So your diagnostics will be hard to read because the compiler doesn't know that 69 is AnimalType.frog
Pointing to a lower level language with a different use case doesn't justify int enums to me.