Some Calendar questions

[bakkot]

• delegate review: Calendar and TimeZone should be brand-checked, not normal, objects #1294 Is there a reason Calendars are passed around as objects, instead of eagerly getting all the methods and passing those around? That would also help with validation. (Sorry if there's discussion of this somewhere.)

• In CalendarEquals there are observable ToString calls. It might be worth doing a preemptive strict equality check, so that the common case of comparing a calendar to itself can avoid calling any user code.

• The documentation says "calendar.fields [...] is called indirectly when using the from() static methods and with() methods". It's called in a lot more places than that, e.g. in toPlainYearMonth (via CalendarFields); is that omission intentional?

• Why does CompareCalendar exist? I do not tend to think of calendars as being comparable.

[ptomato]

I will try to address all the other points later but as for (1) there is an existing discussion starting at #1294 (comment).

tl;dr: Yes, that would be possible, and has some advantages, but leads to existing PlainWhatever and ZonedDateTime objects being broken if Temporal.Calendar.prototype is mutated, and it's my opinion that that the advantages don't weigh strongly enough.

[bakkot]

Sweet, thanks for the pointer.

[ptomato]

(2) Sure, that seems harmless.

(3) I don't think it was intentional. We can just change this.

(4) In, for example, Temporal.PlainDateTime.compare(), if the dates are the same but the calendars are different, then the function needs to return -1 or +1 in order to have some sort order, so we picked lexicographical comparison of the calendar ID. Previous discussion on this and rationale in #588 and #625.

[bakkot]

if the dates are the same but the calendars are different, then the function needs to return -1 or +1 in order to have some sort order

No, it doesn't. Returning 0 is the correct thing to do for two items for which neither comes before the other. That's a useful thing to do; indeed, that's why we made Array.prototype.sort stable. I'll open a new issue for this.

[ptomato]

Personally I agreed with that, but do check #588 and #625 before opening a new issue; there was a large amount of opposition to that position and I thought the reasons given were valid.

[ptomato]

Of the above points I believe that only (2) and (3) still apply, and (2) is normative, so I'll make sure that gets done before we say that the Stage 3 conditions have been resolved.

[bakkot]

Note that (2) applies equally to TimeZoneEquals.