tc39/proposal-decorators

`addInitializer` mismatch between explainer and spec

pzuraq opened this issue · 3 comments

pzuraq commented

The explainer says that addInitializer does not exist on the context object passed to field decorators, but the spec says that initializers are added unconditionally to all context objects. This was a mistake when writing the spec, but @rbuckton has noted that it's not particularly an issue conceptually since addInitializer still has the same timing semantics (e.g. it runs before the field is initialized), so it does not give fields any new capabilities. That said, it is an extra function that has to be created and managed.

ljharb commented

i'm confused; why wouldn't we have always wanted fields to be able to add initializers? what's the difference between addInitializer(a) and having the field set to b(), or having the field set to a(), b()?

rbuckton commented

i'm confused; why wouldn't we have always wanted fields to be able to add initializers? what's the difference between addInitializer(a) and having the field set to b(), or having the field set to a(), b()?

Initializers added via addInitializer will run before any field initializers, but I agree that there's no sense in special casing here.

  • 👍1