Editorial: Arrange contents consistently

[ben-allen]

Resolves the following aspects of #405:

Placed Prototype Object properties in the following order for all Intl Objects:

1. Intl.Foo.prototype.constructor
2. Intl.Foo.prototype.resolvedOptions ()
3. Intl.Foo.prototype [ %Symbol.toStringTag% ]
4. ...Foo-specific properties in alphabetic order...

Gathered all Abstract Operations associated with each Object into the Abstract Operations section for that Object. Previously Intl.DateTimeFormat, Intl.Locale, and Intl.NumberFormat had several Abstract Operations appear inside the constructor clauses of those Objects.

[anba]

ECMA-262 sorts built-in properties alphabetically, with Symbol-keyed properties being sorted to the end. Does it make sense to follow in ECMA-402?

[gibson042]

I'm ambivalent about that, especially dropping resolvedOptions at a varying position for each prototype—there's something to be said for a simple rule, but also for tweaking that rule to highlight internal consistency. On balance, I think I prefer the latter, ideally including documentation justifying it.

[ben-allen]

My preference strongly matches @gibson042's -- resolvedOptions in predictable place, add text to the style guide explaining the choice. Should we discuss it at TG2? @anba

[gibson042]

Looking at the rendered spec, I think I do have a slight preference for Symbol.toStringTag properties being after string-keyed properties—especially since they might not even be universal in the future.

[gibson042]

Non-blocking, but I have a moderate preference for constructor-specific operations being in their respective Constructor sections, e.g.

• DateTimeFormat Objects
  1. The Intl.DateTimeFormat Constructor
     1. Intl.DateTimeFormat ( [ locales [ , options ] ] )
     2. CreateDateTimeFormat ( newTarget, locales, options, required, defaults )
     3. ChainDateTimeFormat ( dateTimeFormat, newTarget, this )
     4. DateTimeStyleFormat ( dateStyle, timeStyle, styles )

In addition to locality benefits, it reduces the divergence between constructors that use such helper operations and those that do not.

[ben-allen]

Thanks for this one! I was torn between leaving them where they were or putting them down with the rest of the AOs. The least-bad argument I have for moving them down is the possibility of those AOs getting called from elsewhere in the spec -- though upon brief perusal the only place that seems to happen is the call to SetNumberFormatDigitOptions from the PluralRules constructor. I'll move them back.

[gibson042]

Intl.Locale is not a service constructor, so we should probably just follow ECMA-262 conventions—string-keyed properties alphabetically, then symbol-keyed properties alphabetically (i.e., Symbol.toStringTag last).

[gibson042]

Intl.Locale is not a service constructor, so we should probably just follow ECMA-262 conventions—string-keyed properties alphabetically, then symbol-keyed properties alphabetically (i.e., Symbol.toStringTag last).

This one still stands; please move at least Intl.Locale.prototype [ %Symbol.toStringTag% ] to the end of "Properties of the Intl.Locale Prototype Object".

[gibson042]

Nit for future reference: we should really rename these to DTF-specific operations to indicate that detail (e.g., DateTimeFormat{Basic,BestFit}Matcher).

[gibson042]

Nit for a followup (if only to minimize review burden): we should also consider alphabetizing these AO lists, and moving/reorganizing where that would hinder comprehension.

[ben-allen]

I'm provisionally skeptical about alphabetizing the AO lists, largely because the decision on when to break from alphabetical order for higher comprehension is difficult / might introduce inconsistencies that are themselves a source of confusion. I'd almost rather just have the rule be alphabetical order, full stop, no exceptions. Open to arguments otherwise, though -- this isn't a strong preference, and it's likely a somewhat uninformed one.

[gibson042]

To clarify, that's in line with my suggestion... the kind of moving/reorganization that I suggest, where necessary, relates to document structure (e.g., FilterLocales and ResolveLocale could be alphabetically sorted as the only children of a "Locale Matching" subsection).

[ben-allen]

ah, that makes a lot of sense! I've put it on my todo list

[gibson042]

Noticed in passing:

Suggested change

	<emu-clause id="sec-Intl.ListFormat.prototype-toStringTag">
	<emu-clause id="sec-intl.listformat.prototype-%symbol.tostringtag%" oldids="sec-Intl.ListFormat.prototype-toStringTag">

(and likewise for RelativeTimeFormat—or we could save both for a bigger id cleanup that also covers non-symbol sections)

[gibson042]

Same comment here regarding constructor-specific operations as for DTF.

[ben-allen]

pushed a commit addressing @gibson042 concerns, largely through dropping the commit that moved constructor-specific AOs down to the section with the rest of the AOs.

[gibson042]

I'd still prefer Symbol.toStringTag properties to follow string-keyed properties, but can live with this.

[gibson042]

Intl.Locale is not a service constructor, so we should probably just follow ECMA-262 conventions—string-keyed properties alphabetically, then symbol-keyed properties alphabetically (i.e., Symbol.toStringTag last).

This one still stands; please move at least Intl.Locale.prototype [ %Symbol.toStringTag% ] to the end of "Properties of the Intl.Locale Prototype Object".