Proposal-temporal: Global objects vs own namespace

[zbraniecki]

I'm a bit concerned about the pollution of the global space with a number of new global objects from this proposal.

Historically, it seems to me that we tried to collect single global per functional area, like Intl, SIMD or WebAssembly and while all "raw" globals like Array, Int8Array, Number etc. are of generic use.

Date&Time operations as presented in the proposal feel to me much more like a specialized functional area that is likely to grow, rather than a generic data type. In particular, it adds multiple objects, and multiple operations and in the description aims to be open for future extension to handle more calendars, operations and types.

Having both, Date and a number of new globals proposed here, feels like confusing design decision that will over time creep up as a cognitive load on the users.
With no chance to deprecate Date anytime soon, I'm wondering if it would make sense to create a single global namespace, say Temporal or DateTime and aim to fill it with methods and objects that would provide the functionality this proposal aims for.

I feel like it makes the global namespace cleaner, including as trivial things as helping with autocomplete.

Any chance the champions would be willing to consider this idea?

[domenic]

I think we should not be concerned about adding 5 globals here, given that every given browser release adds 5-10 new globals. (Estimated.)

[maggiepint]

There's no need for five globals. We could just chain off of a namespace. Temporal is what we're kicking around right now.

[rattrayalex]

Convenience of the API is likely to be key to its adoption over competitors like Date and moment.

The removal of foot-guns is nice, but if it's easier to dodge them with well-honed myMoment.clone() or new Date(y, m + 1, d) etc, many devs may be more likely to stick with their tried and true.

Just 2c in favor of five new globals (they seem worth it to me).

[dilijev]

...if it's easier to dodge them with [globals]...

Concern noted, but FWIW it's not that there's not a precedent for calling new from constructors chained off a namespace. new Temporal.DateTime(...) is similar to new Intl.DateTimeFormat(...) and not especially more cognitive load IMO since the knowledge that you can do that is already baked into the current state of the language.

[rattrayalex]

new Temporal.DateTime(...) certainly wouldn't be surprising or "hard", it's just less convenient. The extra 9 characters – silly as it sounds – may make a difference to developers.

It also "feels less encouraged" if it's not top-level – I could imagine someone saying, "hmm, I'm not doing anything especially temporal here, I probably don't need this niche api" where really they should be saying, "DateTime, that's what I really want! Much better than this vague Date thing".

My impression is that these new api's should be used in many/most of the places Date is used today. If that's incorrect and these are niche api's that should only be used for rare circumstances, it should certainly be behind a namespace.

Again, just 2c

[maggiepint]

The intention is to deprecate date in favor of this API. I suppose I can
make the fact that this replaces date more obvious in the readme.

On Aug 19, 2017 10:54 AM, "Alex Rattray" [e-mail] wrote:

new Temporal.DateTime(...) certainly wouldn't be surprising or "hard",
it's just less convenient. The extra 9 characters – silly as it sounds –
may make a difference to developers.

It also "feels less encouraged" if it's not top-level – I could imagine
someone saying, "hmm, I'm not doing anything especially temporal here,
I probably don't need this niche api" where really they should be saying,
"DateTime, that's what I really want! Much better than this vague Date
thing".

My impression is that these new api's should be used in many/most of the
places Date is used today. If that's incorrect and these are niche api's
that should only be used for rare circumstances, it should certainly be
behind a namespace.

Again, just 2c

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tc39/proposal-temporal/issues/47#issuecomment-323538031,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFxi0h2aYfSXVQIvLBJnZ-IvrvDUf4Ydks5sZyFHgaJpZM4Ol0Fv
.

[domenic]

"Deprecation" isn't really meaningful on the web---it's not like browsers are going to start outputting console warnings every time someone creates a Date, or ever remove Date. In practice it just means that some spec that most developers don't read says "we spec authors don't like this old thing".

So I think the point about developer ergonomics still stands.

[ljharb]

Currently most developers, faced with the current Date API, pull in moment.js - so I think those 9 characters are still much easier than the alternative of bringing in a lib.

[domenic]

I think that's an extremely strong claim, and probably wrong. Maybe most developers who you know, but I think there's a large, large majority that use the standard date library---possibly precisely because it is a bare global.

Do you have any data to back up such a strong claim?

[ljharb]

Fair, I should have qualified my comment - I have no data and I'm sure there are plenty that just use Date; I can understand the argument that bare globals might be easier to use than a namespace, but given the presence of Date, I doubt people will use either alternative without specific instruction or documentation - and I suspect people who seek out that info about dates currently end up using a lib, and in the future would end up using whatever this proposal lands on.

[hollowdoor]

For reference we all know how some people do these kinds of things.

((doc)=>{

})(document);

const doc = document;

const create = document.createElement.bind(document);

It could depend on if a person thinks they are ok with doing that stuff when a given API has a name space, and they also want simpler names. So it's not just two outcomes from multiple globals vs. namespace.

The other possibility is extension. Supposing this proposal gets a namespace (Temporal) maybe some properties containing common values, or host values to inject in the temporal constructors can be put on that namespace.

[felixfbecker]

I agree with this:

It also "feels less encouraged" if it's not top-level – I could imagine someone saying, "hmm, I'm not doing anything especially temporal here, I probably don't need this niche api" where really they should be saying, "DateTime, that's what I really want! Much better than this vague Date thing".

I always liked that JavaScript’s standard library had only the most important things, and those always available globally. Especially when learning the language, having all the important APIs that you need all the time tucked away in modules/namespaces makes the language harder to use.

[littledan]

I guess the current plan is to use a built-in module, right?

[felixfbecker]

I would stand by my point in that case too

[ljharb]

That’s not the current plan as i understand it, because there isn’t built-in modules yet, and because there’s no consensus that even with them, new globals wouldn’t continue to be needed.

[littledan]

By plan, I mean proposal from the champions of this repository. We haven't gotten to Stage 3 yet on this proposal, so there's a lot up in the air.

[ljharb]

Sure, but relying a very uncertain stage 1 proposal would be a surprising choice from the champions of any proposal, let alone a stage 2 proposal.

[littledan]

@ljharb I don't really understand what you mean. Aren't we here to discuss and develop the proposal in this repository?

[ljharb]

Temporal, yes - not builtin modules, which do not exist yet for Temporal to rely on.

[pipobscure]

This is obsolete. Conclusion there is a Temporal namespace object on the global.