Feedback for Stage 2

[littledan]

I'd say this proposal is ready for Stage 2. By that, I'd mean, we are deciding that we have a first draft and want to eventually add a new date standard library, which probably consists of multiple classes and might look something like the current proposal. For next steps to get to Stage 3, I'd recommend publishing the code as a module, encouraging experimentation, and broadly collecting feedback, before coming to final decisions on the API shape.

[ljharb]

I'd still suggest publishing the code from a separate repo, not as TC39, but otherwise I wholeheartedly agree.

[kaizhu256]

how would you roundtrip JSON (#80)?

i feel that's a significant issue that needs addressing before stage-2.

[ljharb]

Why? Many parts of the language aren’t roundtrippable with json: functions, symbols, undefined, etc.

[kaizhu256]

because exchanging the things you mentioned are not important in product-development. temporal objects are. if you make it harder-to-use than Date to exchange/integrate CivilObjects between client <-> server, then why should web-developers care about this proposal from a product-development perspective?

[littledan]

I think we should make the same decision about JSON round-trip here as we do for BigInt: because there is no way to have it automatically round-trip, we should consider throwing on toJSON, or otherwise using the Map/Set approach of providing useless output.

[kaizhu256]

no, thats a terrible decision. it ends up creating needless tech-debt in web-projects, to pre-convert CivilObjects to/from Date, before sending it over the wire as JSON between client <-> server. why deal with extra-risk from all that integration hassle, when you can ship a product more reliably by sticking with just Date-only?

[littledan]

Why would they would convert things to Date rather than to a String directly?

[ljharb]

I’m also confused by that - Dates don’t round trip either, they convert to strings, and are parsed as strings

[kaizhu256]

javascript is not like c++ @littledan. it may be fine and expected of you to write custom wire-protocol class-serializers/constructors in other languages, but thats honestly an obsolete design-pattern in javascript, where everyone expects JSON to do it automatically for them, even if its non-ideally customized/configured for their particular use-case (in the bigger-picture of overall integration-costs, zero-config/zero-tooling JSON-support for a datatype is still a huge win, over a more customizable solution).

[kaizhu256]

@ljharb, yes thats the "roundtrip" behavior for Date. now what is the "roundtrip" behavior for CivilObjects?

[kaizhu256]

issue #80 has been resolved (using .fromString() method for JSON roundtrip).

can someone additionally flesh out the (https://github.com/tc39/proposal-temporal#scenario-based-examples) section in the README with A/B code-examples, showing web-developers how CivilObjects would be easier-to-use than Date before stage-2?

[maggiepint]

Since this is at stage 2, closing