Octal literals have their uses (you Unix haters skip this one)

Brendan Eich brendan at mozilla.org
Thu Jan 12 13:56:53 PST 2012


Right, as Oliver said, 0644 won't just die in real-world non-strict JS 
implementations. It's going to stay for web compatibility until someone 
with enough market share turns it off and survives, and others follow. I 
don't see anyone rushing to risk market share loss for so little in return.

So adding 0o644 support is the way to go. Once again web compatibility 
and evolutionary dynamics require doing two things, in order to (far 
off, hard to predict, might never happen) retire the old form. This is 
not, however "do everything" and so I don't see why we should do 8r644 
as well.

/be

> Thaddee Tyl <mailto:thaddee.tyl at gmail.com>
> January 12, 2012 1:04 PM
>
> +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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Axel Rauschmayer <mailto:axel at rauschma.de>
> January 12, 2012 12:57 PM
>
> +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;
>
> -- 
> Dr. Axel Rauschmayer
> axel at rauschma.de <mailto:axel at rauschma.de>
>
> home: rauschma.de <http://rauschma.de>
> twitter: twitter.com/rauschma <http://twitter.com/rauschma>
> blog: 2ality.com <http://2ality.com>
>
> Oliver Hunt <mailto:oliver at apple.com>
> January 12, 2012 12:44 PM
> 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
>
>
>
> Brendan Eich <mailto:brendan at mozilla.com>
> January 12, 2012 12:30 PM
>> Greg Smith <mailto:greg at bocoup.com>
>> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Greg Smith <mailto:greg at bocoup.com>
> 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.
>
> 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?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120112/2942f2a8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1274 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120112/2942f2a8/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1222 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120112/2942f2a8/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120112/2942f2a8/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1290 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120112/2942f2a8/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1212 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120112/2942f2a8/attachment-0009.jpg>


More information about the es-discuss mailing list