Questions about daysInWeek and monthsInYear

[rwaldron]

Regarding:

• https://tc39.es/proposal-temporal/#sec-temporal.calendar.prototype.daysinweek
• https://tc39.es/proposal-temporal/#sec-temporal.calendar.prototype.monthsinyear

Why are these specified to have more than one step? What is the purpose of all that validation, when the return value is a constant value? There are no this-sensitive semantics here, so there is no reason to validate this. It doesn't matter if this is an initialized calendar or not, because the end result is always the same. Furthermore, why would that operation be allowed to throw? Is there ever a possible state in which an object can't possibly reason that there are 7 days in a week, or 12 months in a year?

Why does it take arguments? There is nothing done with it, except pointless validation.

I would recommend the following changes:

12.4.16 Temporal.Calendar.prototype.daysInWeek ( )
An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement the daysInWeek method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of the daysInWeek method is used.

The following steps are taken:

1. Return 7𝔽.

12.4.19 Temporal.Calendar.prototype.monthsInYear ( )
An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement the monthsInYear method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of the monthsInYear method is used.

The following steps are taken:

1. Return 12𝔽.

[ljharb]

Both are quite this-sensitive in that they read off of internal slots.

Not every calendar system (historically, even if not in current use) has 12 months in a year, or 7 days in a week.

[rwaldron]

Both are quite this-sensitive in that they read off of internal slots.

Yes, to do entirely pointless validation, before returning a constant value.

Not every calendar system (historically, even if not in current use) has 12 months in a year, or 7 days in a week.

This argument holds zero weight when the return values are literally just a constant value.

[rwaldron]

I was even going to offer the suggestion that the authors are not taking into consideration a near future Martian calendar, but that won't matter because all implementations will still just return 7 and 12... unless you make the mistake of passing an uninitialized calendar this object 🤦

[ptomato]

This is an example of a non-12-month year in current use:

new Temporal.PlainDate(2019, 1, 1).withCalendar('hebrew').monthsInYear === 13

I guess what you're saying is that an environment without 402, where the only calendar is ISO 8601 (and where the text that you quoted applies), should not do this validation? I'm not sure I agree with that, since it would cause code like this

Temporal.Calendar.prototype.monthsInYear.call({}, Temporal.Now.plainDateISO())

to return 12 in a non-402 environment but throw in a 402-aware environment, which seems undesirable.

[rwaldron]

I'm not sure I agree with that, since it would cause code like this
Temporal.Calendar.prototype.monthsInYear.call({}, Temporal.Now.plainDateISO())
to return 12 in a non-402 environment but throw in a 402-aware environment, which seems undesirable.

That's only true if you specify it to be so. You can specify that an implementation in a 402-aware environment must also be infallible.

[ptomato]

In a 402-aware environment, the implementation would have to consult the [[Identifier]] slot of the receiver, so it couldn't be infallible.

[ljharb]

Either way, "brand-checking accessors on the prototype" is the way ES typically does these things.

Validation isn't pointless if it would throw when something is mis-called.

[ptomato]

I guess if we had a separate subclass of Temporal.Calendar for each built-in calendar (which was a design that I personally liked, but in the end we didn't go with; see #300, #847, #1195), then we could skip this validation (e.g. in Temporal.GregorianCalendar.prototype.monthsInYear). In the status quo, where 402-aware environments have to read an internal slot of the receiver, I don't believe it's possible to skip this validation.

Therefore I'll close this for now. Feel free to reopen if I've missed something, or if there's other new information that should cause the decision to be revisited, like if these steps are proving bad for performance in implementations.