+1 to that,
too. It does make things easier to read. Ruby has had that
for
decades.
It is a very specific use-case, but I feel like we
shouldn't disregard
non-generic use-cases. 0644 (used in node.js in a
unix environment) is
a non-generic use-case, and as such I feel it
shouldn't just die. That
is why I would like 0644 and 0o644 to
co-exist.
_______________________________________________
es-discuss
mailing list
[email protected]https://mail.mozilla.org/listinfo/es-discuss
+1 to both.
Then we have three kinds of non-decimal literals, for example: 0b1011,
0o732 and 0xFFFF.
For long literals, Java has
started to make "_" as a separator legal, that would be nice to have,
too:
let aLotOfMoney = 120_327_756_228;
I'll just add a caveat to
brendan's comments below though: JScript doesn't support octal in many
(all?) cases, leading to incompatible behaviour when parsing things like
012.
I think the problem with octal numbers isn't a
philosophical hate of octal, inasmuch as it is a general unhappiness
with the existing octal support, namely a simple 0 prefix switching the
parse mode. If we had another (unambiguous) prefix that would (I'm
sure) be fine.
If we were willing to add octal with a
clear prefix I would be fine with that, for consistency with hex, I'd
lean towards 0o<...>, but I'm open to any suggestions that people
may wish to add. Personally I'd also like a binary form, a la 0b....,
but I'm unsure how useful regular developers would find that (I don't
write "realworld" JS so my needs don't always align with those of
regular developers).
--Oliver
January 12, 2012
12:08 PM
To me this
seems like an exception rather than a common problem. Most APIs / tools
don't use octals for this type of thing. Seems unnecessary to add to
the language for this one use case.
"Add to the language" is not accurate. Octal is *already* supported by
JS engines today, and again, AFAIK, it is required for web
compatibility. Banishing octal to the non-normative Annex B, banning it
from strict mode -- that does not remove octal from JS in reality.
Given this, the shoe is rather on the other foot: strict-mode has one
more drawback from the point of view of a non-trivial cohort of users
(Node.js hackers who wrangle Unix permissions).
Not
a Linux hater by any means, just the parseInt thing doesn't bother me
for this one situation.
That's nice, but Node.js supports JS non-strict and people use it
freely, including not quoting octal literals (the API works with string
inputs too, so explicit parseInt is not required).
The problem for CoffeeScript users can be solved quickly via 0o
prefixing. The problem for JS users is also easy: don't use strict mode.
Is this really what we want? What good have we done by banning octal in
strict mode?
Or am I wrong and there are other common uses for octal
literals?
The only use case I'm citing here is Unix permission modes. That's
enough.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
To me this seems like an
exception rather than a common problem. Most APIs / tools don't use
octals for this type of thing. Seems unnecessary to add to the language
for this one use case.
Not a Linux hater by any
means, just the parseInt thing doesn't bother me for this one situation.
Or am I wrong and there are other common uses for octal literals?
