Rename Deno into deno

[Alexsey]

In TypeScript/JavaScript in almost all conventions camelCase is used for variable names except of classes/constructors and only classes/constructors are named in PascalCase. So having Deno, the core object of the infrastructure in PascalCase is breaking the common convention for no reason. How about renaming it to deno before it's not too late?

[kevinkassimo]

We used to (at least conventionally) have it as deno in the past when we import the APIs as if it was a module (import * as deno from "deno", this usage is no longer available). However, PascalCases are also used in JS e.g. for Math/Reflect to represent namespaces, so it is actually following JS/TS convention

[Alexsey]

Yes, sometimes namespace objects of core JS/TS are named in PascalCase. But Deno is an env variable, like window in browsers or process in NodeJS

Upd: I may even assume that the convention of naming in core JS is taking its roots from Java. Because as we know from history of JS, the initial version of JS syntax was mostly taken from Java (this is why we have this link in its name), and later the TC39 was just following the initial convention, even though it's not in line with new "traditions", just in the sake of consistency

[ry]

It seems modern web namespaces use lower-case names. Example https://developer.mozilla.org/en-US/docs/Web/API/Performance

Also "deno" is one less button to type vs "Deno".

[piscisaureus]

We used to (at least conventionally) have it as deno in the past when we import the APIs as if it was a module (import * as deno from "deno", this usage is no longer available). However, PascalCases are also used in JS e.g. for Math/Reflect to represent namespaces, so it is actually following JS/TS convention

It's still available though: const deno = Deno; and you're all set.

[piscisaureus]

Casing has nothing to do with modern vs legacy.
The EcmaScript standard typically uses UpperCamelCase for namespaces, even those that are not classes (e.g. Reflect, Symbol, Math).
DOM standards which are defined by W3C use lowercase names (e.g. document, window, location); performance falls in the latter category.

[kitsonk]

Since both seem to be current and valid semantics, I would say there is no value in the code churn then.

[methodbox]

Since both seem to be current and valid semantics, I would say there is no value in the code churn then.

Just my two cents: I think you should buck the trend and be radical (keep it) like Deno vs. Node (or is it node?).

[Fenzland]

DOM, BOM or environment api typically using camelCase:
e.g. document, location, history, navigator, performance, localStorage...
and the UpperCamelCase names are reserved for their constructors (often with the same name):
HTMLDocument, Location, History, Navigator, Performance, Storage.

EcmaScript modules use UpperCamelCase:
Math, Reflect, JSON...

EcmaScript functions use camelCase:
encodeURI, setTimeout...

I think that both Deno and deno with a constructor Deno are conventional.

[Alexsey]

It's still available though: const deno = Deno; and you're all set.

Yes, but you should not do that. I think it's obvious why

Casing has nothing to do with modern vs legacy.

Are you sure that is not because in Java everything is a class? Because we have words of Brendan Eich The diktat from upper engineering management was that the language must "look like Java"

The EcmaScript standard typically uses UpperCamelCase for namespaces, even those that are not classes (e.g. Reflect, Symbol, Math).

That's, right. And since Deno is not an ECMAScript module and not a constructor, it should not be in UpperCamelCase but in camelCase

[kitsonk]

Yes, but you should not do that. I think it's obvious why

Why is it obvious?

That's, right. And since Deno is not an ECMAScript module and not a constructor, it should not be in UpperCamelCase but in camelCase

But it isn't a DOM namespace either, so it shouldn't use camelCase. Same logic.

[Alexsey]

Why is it obvious?

Because there are expectations that other people have about your code. And such things would break the expectations and bring confusion. Also, it would break the consistency. And it would bring even more confusion

Let me give you some real-world examples: you are not overriding ES3 array methods like sort, reverse or splice for them not to modify the array they have been called on. You are not overriding push for it to return this instead of length to make it chainable. You use typeof although it returns object for null. All these are design mistakes that TC39 cannot fix because they can not break the web and you would not solve because you don't want to bring confusion to your code. And for the same reason, you should not do const deno = Deno;

But it isn't a DOM namespace either, so it shouldn't use camelCase. Same logic.

No. The logic is that Deno is a host object, and we have examples of host environments where host objects are used in camelCase. And camelCase is a de-facto standard in modern JavaScript. So there is no reason to break the consistency and expectations

[kitsonk]

Because there are expectations that other people have about your code. And such things would break the expectations and bring confusion. Also, it would break the consistency. And it would bring even more confusion

Modules are self contained and should not lead and of the Deno APIs outside of the module using that namespace.

The logic is that Deno is a host variable, and we have examples of host environments where host variables are used in camelCase.

It isn't a host variable. It is a global namespace. We have examples where these are CamelCase (e.g. Reflect).

And camelCase is a de-facto standard in modern JavaScript.

A pointed out above, it is not the de-facto in modern JavaScript. TC39 continue to use CamelCas. It is the W3C in the browser which have used camelCase.

[Alexsey]

Modules are self contained and should not lead and of the Deno APIs outside of the module using that namespace.

I'm not talking about technical aspect, but about mental. The problem you are talking about would be solved with Realms. But even when we would have Realms you still should not change interfaces of array methods and other stuff like that. Because it is confusing

Unless you are the only person who is working with the codebase - in this case, you can do whatever you want, of course

It isn't a host variable. It is a global namespace. We have examples where these are CamelCase (e.g. Reflect).

Deno is a host object
Reflect is a native object of ECMAScript spec i.e. not a host object

A pointed out above, it is not the de-facto in modern JavaScript. TC39 continue to use CamelCas. It is the W3C in the browser which have used camelCase.

And I have written before why TC39 continues to use UpperCamelCase even though in userland and environments de-facto standard is camelCase

[methodbox]

Just so we are all on the same page, deno (lowercase intentional) as a CLI Linux binary is an environment variable (you can prove this by just outputting your env with printenv) and a path variable (as you add it to your $PATH) - path variables are also env variables, but not all env variables are path variables.

Deno (capitol D intentional) is a namespace that doesn’t exist in the path or env or for that matter, Unix environment.

XDG_SESSION_ID=669
HOSTNAME=git.************.net
SELINUX_ROLE_REQUESTED=
TERM=xterm-256color
SHELL=/bin/bash
HISTSIZE=1000
SSH_CLIENT=10.200.6.98 52764 22
SELINUX_USE_CURRENT_RANGE=
SSH_TTY=/dev/pts/0
USER=root
LS_COLORS=...
MAIL=/var/spool/mail/root
.......................................................///  Your path  ///......................
PATH=............../usr/local/git/bin:/root/bin:/usr/local/bin/deno
PWD=/root
LANG=en_US.UTF-8
SELINUX_LEVEL_REQUESTED=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
LOGNAME=root
SSH_CONNECTION=10.200.6.98 52764 10.200.6.160 22
LESSOPEN=||/usr/bin/lesspipe.sh %s
XDG_RUNTIME_DIR=/run/user/0
_=/usr/bin/printenv

Neither of these is a host variable - that isn’t a thing in the Unix world, unless you’re referring to $HOST which is sometimes an alias for $HOSTNAME; not the same thing. Let’s just throw that terminology out.

The system-level binary name should never be capitalized in the tradition of Unix system namespace variables, but there’s nothing saying it can’t be. For that one, deno makes perfect sense. If you don’t think so, I encourage you to become a Linux admin and change it or just set a different env variable alias in your $PATH.

The JavaScript namespace should probably use the same standards for naming any part of the JS API, unless, like node, it follows the system-level convention, which as I already stated, is all lower-case. If we follow the JS API and make it “webby” it’s UpperCamelCase.

Personally, as you'd be working from the command line with this and you need to separate the STDOUT and STDIN instances of deno from the JS environment instance of Deno, it's also less confusing to keep them intentionally different.

The variable association is an important distinction not just as a matter of technicality and preference, but how it functions in the system environment.

If you never leave the JS environment (think process.argv[x] in the node world) then this might not make much sense, but it could cause issues where keeping the namespace UpperCase and the env variable lowercase makes sense.

[methodbox]

Modules are self contained and should not lead and of the Deno APIs outside of the module using that namespace.

I'm not talking about technical aspect, but about mental. The problem you are talking about would be solved with Realms. But even when we would have Realms you still should not change interfaces of array methods and other stuff like that. Because it is confusing

Unless you are the only person who is working with the codebase - in this case, you can do whatever you want, of course

It isn't a host variable. It is a global namespace. We have examples where these are CamelCase (e.g. Reflect).

Deno is a hots variable
Reflect is a native object of ECMAScript spec i.e. not a host variable

A pointed out above, it is not the de-facto in modern JavaScript. TC39 continue to use CamelCas. It is the W3C in the browser which have used camelCase.

And I have written before why TC39 continues to use UpperCamelCase even though in userland and environments de-facto standard is camelCase

It's actually not a host variable, (AFAIK this term exists solely within the SQL realm) which is why I was confused. It's a host object; the name is assigned to the host object, the object is global, making the name part of the global namespace. The differentiation being the definition of the name and the object it is referring to. Exa. "car" is a word, but a car is an object; the word is a noun. (Sorry, but this is actually important for clarity).

4.3.8 host object
object supplied by the host environment to complete the execution environment of ECMAScript
NOTE Any object that is not native is a host object.

[Alexsey]

I'm sorry for confusing anyone. Everywhere instead of "host variable" should be "host object". I'll change my previous comments but leave this one so @methodbox comment would not lose sense

[kitsonk]

@ry it feels like we should either live with Deno which seems to be doing ok, or move to deno quickly.

[bartlomieju]

I agree with @kitsonk that Deno works fine and we should leave it as is.

EDIT: Oooops I see there are a lot of +1s for renaming to deno.

[kitsonk]

Again though Deno seems to be fine, but I don't really care. I do think leaving this open for debate though is confusing. If we are going to do it, we should have done it a while ago now, IMO. Closing this issue one way or another feels like something that is a pre-req for 1.0 (ref: #2473).

[ry]

Ok - sticking with Deno!