ECMA-402 contents should be arranged more consistently

[gibson042]

Suggested template for Foo functionality:

• Foo Objects
  1. The Intl.Foo Constructor
     1. Intl.Foo ( [ locales [ , options ] ] )
  2. Properties of the Intl.Foo Constructor
     1. Intl.Foo.prototype
     2. Intl.Foo.supportedLocalesOf ( locales [, options ] )
     3. Internal slots
  3. Properties of the Intl.Foo Prototype Object
     1. Intl.Foo.prototype.constructor
     2. Intl.Foo.prototype.resolvedOptions ()
     3. Intl.Foo.prototype [ @@toStringTag ] (or maybe this could be absent from new extensions?)
     4. ...Foo-specific properties in alphabetic order...
  4. Properties of Intl.Foo Instances
  5. ...other Foo-specific surface area...
  6. Abstract Operations for Foo Objects

The biggest differences of this as compared to http://tc39.es/ecma402/ are in the ordering under "Properties of the Intl.Foo Prototype Object" (which currently all go like "constructor", "@@toStringTag", ..., "resolvedOptions") and in pushing abstract operations to be after the references to them (rather than before the Constructor definition as they are now).

It also looks like a great deal of the constructor code could be abstracted:

1. (since PluralRules, cf. Should all new constructors throw when called as a function? #384) If NewTarget is undefined, throw a TypeError exception.
2. If NewTarget is undefined, let newTarget be the active function object, else let newTarget be NewTarget.
3. Let obj be ? OrdinaryCreateFromConstructor(newTarget, proto, internalSlotsList).
4. Let requestedLocales be ? CanonicalizeLocaleList(locales).
5. If options is undefined, then
   1. Let options be ObjectCreate(null).
6. Else
   1. Let options be ? ToObject(options).
7. Let opt be a new Record.
8. Let matcher be ? GetOption(options, "localeMatcher", "string", « "lookup", "best fit" », "best fit").
9. Set opt.[[localeMatcher]] to matcher.
10. Let localeData be constructor.[[LocaleData]].
11. Let r be ResolveLocale(constructor.[[AvailableLocales]], requestedLocales, opt, constructor.[[RelevantExtensionKeys]], localeData).
12. Set obj.[[Locale]] to the value of r.[[locale]].
13. Return obj.

[sffc]

This seems straightforward and it can help prevent errors when merging proposals, implementing the spec, etc. It should be done in a quiet time when there are not other big PRs open.

[ben-allen]

#923 rearranges the specifications for each Intl object to match the template given by @gibson042.

Is there still interest in abstracting away the duplicative constructor code? I'm a big fan of the idea, but given that different Intl Objects have different options reads interspersed through those sections, the most straightforward way to abstract it out would require normative changes to the order of those options reads.

[gibson042]

Is there still interest in abstracting away the duplicative constructor code?

Yes, I'd still love to see that.

I'm a big fan of the idea, but given that different Intl Objects have different options reads interspersed through those sections, the most straightforward way to abstract it out would require normative changes to the order of those options reads.

I think we can get pretty far editorially... AFAICT, there's variation only on

• how to deal with undefined NewTarget (i.e., invocation as a function rather than as a constructor with new), and
• how to consume options, and
• (for Collator and DateTimeFormat and NumberFormat and RelativeTimeFormat) early reads of options properties that can potentially affect ResolveLocale [by overridding keywords in the requested locale identifiers, and in the case of Collator by selection of locale data]

...all of which can be parameterized in a common constructor operation.

We can also get even further if normative changes are on the table to e.g. snapshot options objects early in construction, which would be great but should wait for completion of the editorial part so we can better assess the impact of such changes.