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

Lasse Reichstein reichsteinatwork at gmail.com
Fri Jan 13 01:30:40 PST 2012

I'd like having 0o777 (and 0b1111!) but I thought the reason for removing
the existing octal literals was that they were surprising and error-prone
(and behaving erratically in different settings, so, e.g., 0100 != +"0100").
That reasoning still stands.

I can't say whether removing them from strict mode was really a benfit. It
made strict mode more compatible across browsers than non-strict mode ever
was, but it might also have made moving code from non-strict to strict
slightly harder.
Personally, I'd go for strict mode to be sure that my numbers were *not*
interpreted as octal.
But that's what's being argued here - converting existing code (or existing
programmers) to strict mode is hampered by them not being able to use the
octal numbers they are used to.

Well, these are obviously not programmers that want strict mode to begin
with (since it requires very little effort to change the octal literal to a
string). It's people that would choose strict mode only if it was trivial
or they had a compelling reason for doing it.

I don't think people writing non-strict code as their default for node.js
is a problem solved by changing strict mode.
It might be changed if there was an actual advantage for the programmers in
using strict mode, which there hasn't been - it's not faster, it's not
simpler, and it's not what they are used to, and being more compatible
between ECMAScript implementations makes no difference when writing for
just node.js.


On Fri, Jan 13, 2012 at 7:47 AM, Brendan Eich <brendan at mozilla.com> wrote:

> 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 <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 <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 <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 <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 <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/20120113/07ec2e27/attachment-0001.html>

More information about the es-discuss mailing list