[eyelidlessness]

I like enum and use field declarations as much as possible. But I use classes as value types so my goal is to make them as concise as an equivalent function if possible. The fact that they’re classes is just an implementation detail primarily for performance purposes.

There are a few others, mostly discouraged these days (namespace and module runtime keywords come to mind). Mostly they’ve treated these as legacy mistakes (good!), but they introduced a new one recently that baffles me given that posture: `accessor` as a shorthand for getter/setter pairs, with no clear authoring benefit for working with the underlying private value.

[MrJohz]

In that case, why not just create an object? With a constructor function, that could look something like

    (name: string, age: number) => ({ name, age: age * 2 })

Or even just without the constructor, if the data is so simple:

    { name: "Bill", age: 62 }

I'd have thought that would be the quickest option, because then you're not messing around with prototypes at all.

Also, what do you mean by the accessor shorthand? I don't know what you mean off the top of my head, and searching for it has just brought me back to this post!

[eyelidlessness]

Using a class has some JIT optimization benefits if you always construct a value of the same shape.

Accessors: https://devblogs.microsoft.com/typescript/announcing-typescr...

[MrJohz]

That's true of objects too, as long as they have the same shape (which Typescript naturally helps with!). As long as the optimising compiler can see that your objects all have the same shape, and that you're always using the same properties, you're golden.

I hadn't noticed the accessors thing before, but it looks like that's an ECMAScript/TC39 thing, I guess to support the decorator implementation. Thanks for the link!