|
| 1 | +# Apr 2, 2020 |
| 2 | + |
| 3 | +## Attendees: |
| 4 | + |
| 5 | +- Ujjwal Sharma (USA) |
| 6 | +- Jase Williams (JWS) |
| 7 | +- Philip Chimento (PFC) |
| 8 | +- Philipp Dunkel (PDL) |
| 9 | +- Han Jiang (HJG) |
| 10 | +- Ms2ger (MS2) |
| 11 | +- Richard Gibson (RGN) |
| 12 | +- Shane Carr (SFC) |
| 13 | + |
| 14 | +## Agenda: |
| 15 | + |
| 16 | +- TC39 presentation! |
| 17 | + - We are satisfied with how it went. |
| 18 | + - JWS: I was expecting more questions. |
| 19 | + - PDL: I think people have been following it for the past few years, since I've given plenty of updates, and getting their questions answered that way. As long as we keep engaging with people, then we tend to talk about conclusions rather than issues in plenary. |
| 20 | + - PDL: I expect this podcast thing will happen in the next few weeks, so we may get more people experimenting with the polyfill. |
| 21 | +- USA: GCL suggested that we should allow non-24-hour days. |
| 22 | + - Some discussion about how far we already support that with Calendars. |
| 23 | + - Will open an issue about this if there is more to discuss. |
| 24 | +- [#387](https://github.com/tc39/proposal-temporal/issues/387) species use in from() |
| 25 | + - MS2: I have some work-in-progress on this topic, so we should land it first as well. |
| 26 | + - SFC: With the Calendar data model, from() delegates to the Calendar. If the Calendar has to decide what type it's going to be constructing, I don't see how you would make Calendar.dateFromFields() construct a polymorphic date. It would just construct the default Date. |
| 27 | + - PFC: dateFromFields could receive the constructor, or it could return a property bag. |
| 28 | + - SFC: We had a separate discussion about what type it should return, and I think it should return a Date object. |
| 29 | + - PDL: I think the original behaviour described in the issue is the expected behaviour. |
| 30 | + - SFC: I agree, but this is about dateFromFields not being able to return a polymorphic Date. |
| 31 | + - PFC: from() could also copy the Temporal.Date returned from dateFromFields into the polymorphic type. |
| 32 | + - SFC: OK, we can close the issue. |
| 33 | + - RGN: This increases the burden for virtualization. Anything that has a secret reference to a constructor has to be patched for SES, for example. |
| 34 | + - PDL: That is not correct. All the Temporal classes would remain the same across SES. What we want to disallow is data from the outside. |
| 35 | + - RGN: Is it not the case that e.g. DateTime.from has reference to data from outside Temporal, e.g. time zones? |
| 36 | + - PFC: All time zone access goes through Temporal.TimeZone. |
| 37 | + - RGN: Right, but it can't have secret access, it has to do a Get. |
| 38 | + - MS2: That's the case. |
| 39 | + - SFC: Another possibility is to give Calendar a field for DateTimeConstructor, e.g. |
| 40 | + - RGN: I don't want to go down that road if everything looks OK as is. |
| 41 | +- [#403](https://github.com/tc39/proposal-temporal/issues/403) solve enumerability with a toObject() method? |
| 42 | + - USA: What do people think of this suggestion? |
| 43 | + - SFC: I would prefer toJSON() return the object and toISOString() return the string. It would help preserve the calendar information in serialization. |
| 44 | + - PDL: How do you clearly separate inside a JSON whether a particular object is a Temporal object? With string parsing, you can easily see whether a string is an ISO 8601 string. And if you keep it as a string, then most databases can also correctly handle it as a date. |
| 45 | + - RGN: I disagree; detecting when deserializing JSON whether any given value is or is not Temporal, is equally challenging whether that value is a string or object. However, I don't think that affects the decision whether toJSON() should return a string or object. For example, if you say that anything that *can* deserialize to a Temporal.Date, *should*, then you will include things that should not be included, and that's the case regardless of strings or objects. |
| 46 | + - USA: You can pass either strings or property bags to from(), so that doesn't matter for deserialization. |
| 47 | + - PDL: I'm thinking in terms of what the typical web developer does. If you are serializing a Temporal object to send as a request payload to some backend, then an ISO string is far more convenient. |
| 48 | + - RGN: I agree, in the common case, then you probably want toJSON() to be a string, because it's probably for interchange with a remote system. |
| 49 | + - PDL: I agree with having a toObject() but I don't want toJSON() to return an object. |
| 50 | + - USA: raw() that returns a record? |
| 51 | + - SFC: getFields()? |
| 52 | + - PDL: I don't want to wait for the records proposal. |
| 53 | + - RGN: We'd want to add toRecord() later if the records proposal makes it in. |
| 54 | + - PDL: I second getFields() or toFields(). |
| 55 | + - USA: Agreed. By Record I meant the generic sense. |
| 56 | + - RGN: Slight preference for getFields() over toFields(). |
| 57 | + - Consensus on calling the method getFields(). It returns a new JS object whose prototype is Object, with all the fields as enumerable, writable own data properties. |
| 58 | +- Next steps for calendar |
| 59 | + - [#354](https://github.com/tc39/proposal-temporal/issues/354) How is data passed into the calendar methods? |
| 60 | + - SFC: We have Calendar.p.dateFromFields that works as expected. But when you call Temporal.Date.p. |
| 61 | + - PDL: Am I understanding correctly? Because we proxy operations into Calendar, only full Temporal objects are passed into Calendar operations, so it should throw if it gets an object that doesn't have the slots? |
| 62 | + - SFC: But how does a custom calendar access those slots? Built-in calendars would access the slots directly. |
| 63 | + - USA: With getFields()? |
| 64 | + - SFC: If you don't have getters, then they shouldn't be on getFields() (??) |
| 65 | + - PDL: We do have the guarantee that the Date object being passed into plus/minus/etc., that it has a calendar property that is identical to the calendar that it's being proxied into. So the calendar doesn't actually need to get the ISO fields. |
| 66 | + - SFC: There's still a loop, though, because (??) |
| 67 | + - PDL: I second the proposal of option 1. I would also go further and add isoHour, isoMinute, and so on. |
| 68 | + - USA: All the hours are ISO hours. |
| 69 | + - PDL: I don't think that's correct, since the day may not begin at midnight. |
| 70 | + - SFC: I agree, on DateTime and Time we'd have the isoHour, etc. fields as well. |
| 71 | + - PDL: This makes it clearer why ISO is our default, as well, because any object, no matter what calendar, has knowledge of what it is in ISO. |
| 72 | + - PFC: I'm not opposed to option 1, but the reason why I prefer option 2 is because I think the less API that we add to deal with calendars, the better. I think it will be confusing for programmers, to see year, month, day, isoYear, isoMonth, isoDay getters, when in the common case they'll be identical. We'll see code that mixes them depending on which came up first in the programmer's documentation search. |
| 73 | + - JWS: Agreed. |
| 74 | + - SFC: Is there any other type in the JS ecosystem where you pass data to a constructor and can never get it again? That seems strange. |
| 75 | + - PDL: Option 3 would be a middle ground between option 1 and option 2 in that regard. |
| 76 | + - USA: Can we get consensus on getISOFields() (slightly modified option 3)? |
| 77 | + - Consensus on getISOFields(). |
0 commit comments