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

Brendan Eich brendan at mozilla.com
Thu Jan 12 22:47:14 PST 2012


The API in question takes a string and does parseInt if necessary. 
That's not the issue. There is real code using octal and it won't change 
to quote the numeric literal, and it won't adopt strict mode. Meanwhile 
CoffeeScript is trying to target strict mode. It  can cope, but we're 
left with non-strict Node.js JS source code as default, with no 
incentive to change.

What was the good, what benefit was achieved, by banning octal from 
strict mode? Since it is required for web compatibility, it is already 
in the spec. Adding 0o is not adding an unnecessary feature if there are 
valid use cases for octal. Or would you be ok if we simply allowed 
0-prefixed octal in strict mode?

/be

> Lasse Reichstein <mailto:reichsteinatwork at gmail.com>
> January 12, 2012 10:15 PM
> Seems like a library interface that isn't well thought through:
> Accepting a number as input, but it's only reasonably written in one
> base. Then it's not really a number, but rather a formatted string, so
> the chmod function should take a string as argument and do its own
> parseInt(_,8) on it (and accept other formats too, like "a+rw" or
> "rwxr--r--").
>
> Don't try to fix a single broken interface by adding unnecessary
> features to the language!
> /L 'not a Unix hater, but probably a chmod hater'
>
> Wes Garland <mailto:wes at page.ca>
> January 12, 2012 11:51 AM
> I'll chime in with my vote - I would LOVE to be able to use octal 
> literals again in GPSEE for setting file permissions.
>
> chmod("filename", parseInt("777", 8))
>
> ^^^^ just looks stupid when  chmod("filename", 0777) would work just fine.
>
> Wes
>
>
>
>
>
> -- 
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102
> Brendan Eich <mailto:brendan at mozilla.com>
> January 12, 2012 11:11 AM
> [Resending reply with elaboration. /be]
>
> Yes, the ability to quote the octal literal with Node's APIs came up 
> on the gist, but it's not enough.
>
> Quoting is easy to forget, and making the runtime convert string 
> (literal) to number is inefficient compared to having JS do it at 
> compile-time, and making the runtime (even via a call to parseInt) do 
> it also increases bug habitat ever so slightly.
>
> Mainly, users don't have to shun octal in non-strict mode, and they do 
> not in Node code I have seen. They won't be adopting strict mode as 
> far as I can tell. Banning octal is just one more reason for those who 
> *might* adopt strict mode to reject it.
>
> Agree on parseInt. Old dog, hard to change (runtime-only errors are 
> migration- and user-hostile). Not sure what to do there.
>
> /be
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Dean Landolt <mailto:dean at deanlandolt.com>
> January 12, 2012 11:02 AM
> /cc es-discuss (sorry Brendan -- you always seem to be the target of 
> my reply-all fails)
>
>
> Dean Landolt <mailto:dean at deanlandolt.com>
> January 12, 2012 11:01 AM
>
>
>     Sorry, are you seriously proposing that Node.js users when they
>     specify file permissions should manually write that out? Come on!
>     Sorry, that's just way too verbose and ugly.
>
>
> They don't have to, an octal string mode works just fine:
>
>   fs.chmod(path, "0777")
>
> Octals can be little hazardous, and not just to noobs, but the hazard 
> isn't with literals, it's with parseInt:
>
>   parseInt("022") // 18
>
> Better than losing octal literals would be to throw out the unary 
> version of parseInt. Guessing the radix is crazy! I'm indifferent to 
> whether octals stay the same or grow a o, but parseInt could really 
> use some love!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120112/2bef9756/attachment-0001.html>
-------------- 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/2bef9756/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1242 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120112/2bef9756/attachment-0005.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/2bef9756/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1305 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120112/2bef9756/attachment-0007.jpg>


More information about the es-discuss mailing list