Temporal.now should maybe be Temporal.Now?

[domenic]

I think the standard for namespace objects (such as Temporal or Math) is to capitalize them.

Temporal.now is a namespace object that lives in another namespace object, but I think it should still be capitalized?

[ptomato]

Temporal is currently in Stage 3 so we're no longer considering name changes, so I'm going to close this suggestion.

(Thanks for taking the time! I agree that by one possible mental model it's inconsistent. I'm not sure of the rationale, as Temporal.now existed long before I became involved with the proposal, but I'd guess because it was added in order to be a singleton object that is patched out by environments like SES, and that doesn't have the same connotation as a namespace. On the other hand, the intuition does seem to point towards adding a @@toStringTag property to it.)

[sffc]

I do not recall the casing of Temporal.now coming up in discussions. Previously it was a function, and I suggested changing it to a namespace object at #236 (comment). We did not discuss changing the case at that time.

I think it is worth reopening this thread on the grounds that we are getting more reviews from ECMAScript Educators.

[ptomato]

I'm concerned about the effect that would have on implementors being able to trust that Stage 3 means done, as we are already incorporating a lot of implementor feedback already that could be disruptive to other implementors. But let's discuss it at the next champions meeting, then.

[ljharb]

Are there any conventions for capitalization of nested namespace objects in userland we can look to?

[domenic]

The ones I'm aware of are in Microsoft's libraries e.g. https://docs.microsoft.com/en-us/previous-versions/windows/apps/br229774(v=win.10) .

[ljharb]

I tried to google for stuff, and all I found was:

• https://addyosmani.com/blog/essential-js-namespacing/ and https://javascriptweblog.wordpress.com/2010/12/07/namespacing-in-javascript/ and other similar articles/tutorials seem to not use any capitalization, even on the root (and matches the apps I worked with prior to module systems becoming a de facto standard, altho sometimes there the root was indeed capitalized)
• I used $.fn a lot back in the day for jquery plugins, but that's really just a shortcut for jQuery.prototype so i doubt it applies
• Backbone has Backbone.Model and friends, but those are all constructors; they don't have any nested plain namespace objects

[syg]

I'm concerned about the effect that would have on implementors being able to trust that Stage 3 means done, as we are already incorporating a lot of implementor feedback already that could be disruptive to other implementors. But let's discuss it at the next champions meeting, then.

As an implementer, name changes don't really concern me as far as post-Stage 3 changes go, so long as it's done before any party has shipped. Temporal has more leeway than other proposals, given its size, that it is unlikely to ship for a while. In this case I'd be more concerned with committee time and reopening bikeshedding discussions, but a strict timebox would solve that.

Another data point that shows renaming is a more sanctioned-than-not change is that we've disliked a naming decision so much we renamed it after shipping. Atomics.wake was renamed to Atomics.notify because an engineer at Bocoup realized how difficult it is to disambiguiate "Atomics.wait" and "Atomics.wake" in a spoken sentence. We took advantage of the Spectre-caused unshipping of SABs and Atomics and renamed the method.

[syg]

Are there any conventions for capitalization of nested namespace objects in userland we can look to?

Well, we have convention for namespace objects, which is that they're capitalized. When I ran that survey for whether we should do ArrayBuffer.resizable, not having Resizable capitalized confused a lot of people on whether it was a constructor. My takeaway was the intuition for constructor naming convention is that they are capitalized regardless of nesting. Extrapolating, I'd wager the same for namespaces. I doubt most people would think of nested namespace objects to be sufficiently different from namespace objects simpliciter.

[ptomato]

We discussed this in the champions meeting of 2021-07-08 and if there are no objections to renaming from the editors' side, then none of us have any preference as to whether it is now or Now. However, before making this change and possibly having other proposals diverge from the convention later, we'd like to see some official guidance for proposals on this topic.

[syg]

However, before making this change and possibly having other proposals diverge from the convention later, we'd like to see some official guidance for proposals on this topic.

Seems reasonable. Would you like to add a late-addition discussion item to the agenda for the meeting next week? We have a light schedule.

[ptomato]

However, before making this change and possibly having other proposals diverge from the convention later, we'd like to see some official guidance for proposals on this topic.

Seems reasonable. Would you like to add a late-addition discussion item to the agenda for the meeting next week? We have a light schedule.

Sure, this is done at tc39/agendas#1024

[anba]

When I ran that survey for whether we should do ArrayBuffer.resizable, not having Resizable capitalized confused a lot of people on whether it was a constructor. My takeaway was the intuition for constructor naming convention is that they are capitalized regardless of nesting. Extrapolating, I'd wager the same for namespaces.

This line of argument can also be applied the other way around: If the general expectation was that constructors are capitalised, capitalising Temporal.Now could also mislead users that Temporal.Now is a constructor, too.

[syg]

This line of argument can also be applied the other way around: If the general expectation was that constructors are capitalised, capitalising Temporal.Now could also mislead users that Temporal.Now is a constructor, too.

Yep, from my anecdote alone that's also a reasonable extrapolation. But more than constructors are capitalized, so I feel like the other direction is weaker.

[justingrant]

In the plenary meeting today, someone brought up that it'd be helpful to have a specific definition of what a "namespace" is, under the assumption that by having a clear definition it'd be easier to decide what to do for nested ones. So I took a stab at a definition. I'm probably off-base with some of the terms I use below and perhaps some of the requirements, but the best way to get a good answer on the Internet is always to post a less-good answer. My less-good answer is below.

BTW, the text below assumes that nested namespaces should be capitalized but it's easy to change to lowercase if that's how the winds are blowing. I don't have a strong opinion either way.

---

A namespace is an ECMAScript object that satisfies all of the following conditions:

• Is conceptually like a file path, not a file nor a program. In other words, a namespace is simply a named path of properties that are navigated through in order to get to useful functionality. The namespace doesn't "do" anything on its own.
• Is a singleton object. There should be only one of each namespace object.
• Is only accessible via a property of globalThis or via the properties of another namespace object. A function call must not be required to obtain a namespace object. A namespace object must not be nested inside any non-namespace objects other than globalThis.
• Is an ordinary ECMAScript object that is not callable and not constructable
• Should have only non-enumerable properties.
• Should have only data properties, not accessor properties
• Its prototype is the prototype of Object. It is not a class instance.
• Has @@toStringTag equal to the "full path" of the namespace, e.g. "Foo" for globalThis.Foo, and "Foo.Bar" for globalThis.Foo.Bar
• Should have no mutable internal or observable state, only static-valued properties. (There may be a valid exception here for lazy-initialization or similar optimizations.)
• Properties of a namespace should not change except in unusual cases like virtualization or monkeypatching. In normal circumstances, the namespace object and all its properties should always be available and should not change during the lifetime of an ECMAScript program.
• Has properties that are one of: functions, class constructor functions, data properties that represent constants, or child namespaces.
  • Function names should begin with a lowercase letter
  • Class constructor functions should begin with a capital letter
  • Data properties should represent constants and should be in all-caps snake case, e.g. Math.SQRT1_2. These properties should be [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false.
  • Child namespaces should begin with a capital letter, e.g. Temporal.Now.

[ljharb]

Is a singleton object. There should be only one of each namespace object.

Virtualization of Temporal.now per compartment would mean that Temporal.now doesn't necessarily meet this criteria.

Should have no mutable internal or observable state, only static-valued properties.

This is a bit awkward since all of the Temporal.now methods do in fact have internal and observable state - the current date, time, timezone, etc.

---

The @@toStringTag and capitalization points seem like these aren't criteria for being a namespace, they're consequences of being one - perhaps the criteria and implications could be separated?

[justingrant]

@syg - sorry I had a conflict and couldn't attend today's discussion about namespaces, but sounds like there's a clear path going fwd and you're owning the writeup of "what's a namespace" which I'm sure will be much more clear than my draft above. Correct? If so that's great!

Is a singleton object. There should be only one of each namespace object.

Virtualization of Temporal.now per compartment would mean that Temporal.now doesn't necessarily meet this criteria.

@ljharb - maybe the same caveat applies here as with "no mutable state". Once virtualization or monkeypatching comes into the picture, then the singleton requirement may not apply or may apply with caveats, e.g. will only be a singleton after any virtualization and/or patching is completed. Given that patching and virtualization typically happens at initialization, the meat of user programs will only see a singleton.

Should have no mutable internal or observable state, only static-valued properties.

This is a bit awkward since all of the Temporal.now methods do in fact have internal and observable state - the current date, time, timezone, etc.

The methods have state, but the namespace object doesn't. What I was attempting to convey is that a namespace object is just a dumb container and it delegates all smarts (including state) to the objects that its properties point to.

The @@toStringTag and capitalization points seem like these aren't criteria for being a namespace, they're consequences of being one - perhaps the criteria and implications could be separated?

I have no opinion about how the writeup should be structured. Your suggestion seems reasonable.

[justingrant]

BTW, this was implied above but stating it more clearly: the consensus from yesterday's TC39 plenary meeting was to rename Temporal.now to Temporal.Now.