Proposal-temporal: Are we sure we want casting for static methods besides from?

[littledan]

I see algorithms like ToTime used in just a restricted set of places:

• Temporal.Time.from (good, that's what it's for, modulo #232)
• Temporal.Time.compare
• Temporal.Time.difference

For compare and difference, I feel a bit unsure about whether this algorithm is appropriate to call, or whether we should instead check to see if there's an [[InitializedTemporalTime]] internal slot.

I could imagine people having fun using ISO strings or objects and getting a little bit of terseness, but is this really a common (and intelligible) enough pattern to justify the coercion? Most operations are driven by methods, where you need to call Temporal.Time.from anyway.

[ryzokuken]

/cc @Ms2ger @pipobscure

[ptomato]

Conclusion from yesterday: No casting in .compare() and .difference().

[ptomato]

ToTime() is used as well in e.g. Temporal.Date.prototype.withTime(), I assume by the same argument we don't want a coercion there either?

[pipobscure]

@ptomato correct. We just do a get on the relevant properties of the options bag passed in and:

• Ignore missing bits
• use integer bits
• throw on invalid bits (strings, symbols non-integers)

and because we only get relevant properties superfluous ones are ignored

[littledan]

@pipobscure I think you're forgetting that we agreed to reference internal slots when available, over the properties from Get. If it's a Temporal type, we should still get things based on those internal slots.

[pipobscure]

@littledan correct. That's why my statement started with:

the options bag passed in and:

[littledan]

@pipobscure Sorry, seems like my comment was confused. Which options bag are you referring to? Should Temporal.Date.propotype.withTime take either a Temporal.Time object or options bag (switching on the internal slot?), or should we restrict it to just a Temporal.Time object?

[pipobscure]

Temporal.Date.from({ year: 1976, month: 11, day: 18 })

Would create a date object with my birthday in it. The options bag { year: 1976, month: 11, day: 18 } is a plain JS object and this is one of the main purposes of the from method. So No restricting to real object is not OK.

[littledan]

OK, can we add this to the backlog to discuss next Temporal meeting? It's unclear to me how we are deciding whether to make the judgement this way you're suggesting, or like compare.

[pipobscure]

[ ...timeObjects ].sort(Temporal.Time.compare) or Temporal.Time.compare(timeA, timeB) are the compare use-cases. In this case we can restrict it to just work on objects that already exists.

from is all about creating/casting to such an object. In short without from supporting plain options bags, it's much harder to create them to then use them in compare. This capability in from is also the rationale why the constructors could be reduced to using positional arguments and much stricter in general.

In short: other than being part of Temporal from and compare have nothing in common. Indeed the fact that from is different that allows compare to be stricter.

[littledan]

@pipobscure I was trying to ask, why should withTime accept options bags? Your answer did not mention withTime.

[pipobscure]

Apologies. I thought you meant from.

Indeed withTime like compare can be restricted to actual objects since

(new Temporal.Date(1976,11,18)).withTime(Temporal.Time.from({ hours: 15, minutes: 23 }))

does the trick.

[littledan]

OK, sorry for my misunderstanding and unclear messages. Sounds like we just agree with what @ptomato said: withTime should just check that it got a Temporal.Time, and never has anything to do with an options bag.

[ptomato]

Now that I think about it, what about all the .plus() and .minus() methods? Do we still accept property bags like dateTime.plus({ months: 7, days: 12 }) or is it by the same logic as above easy enough to do dateTime.plus(Temporal.Duration.from('P7M12D'))?

[littledan]

@ptomato This is a bit of a fuzzy thing, but I think .plus() and .minus() cross an ergonomic line where we actually do want to permit them in options bag form.

[gibson042]

This is a bit of a fuzzy thing, but I think .plus() and .minus() cross an ergonomic line where we actually do want to permit them in options bag form.

So, which functions support plain objects and/or strings, and which require typed values? And how are authors supposed to differentiate the categories?

[pipobscure]

This is a bit of a fuzzy thing, but I think .plus() and .minus() cross an ergonomic line where we actually do want to permit them in options bag form.

So, which functions support plain objects and/or strings, and which require typed values? And how are authors supposed to differentiate the categories?

That's precisely the question. I have has several stabs at finding that balance. So I think it's time to let someone else have a stab at creating a definition for where that border-line is.