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

Brendan Eich brendan at mozilla.com
Fri Jan 13 10:15:24 PST 2012


> Lasse Reichstein <mailto:reichsteinatwork at gmail.com>
> January 13, 2012 1:30 AM
> 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.

Are there bug reports or other skidmarks from mistakes of this kind? 
I've never seen one.

https://bugzilla.mozilla.org/buglist.cgi?field0-0-5=content&type0-0-4=substring&type0-0-5=matches&value0-0-5=%22octal%22&list_id=2058643&short_desc=octal&field0-0-0=product&type0-0-1=substring&field0-0-1=component&type0-0-6=substring&field0-0-4=status_whiteboard&classification=Components&value0-0-2=octal&field0-0-6=cf_crash_signature&query_format=advanced&type0-0-3=substring&field0-0-3=short_desc&value0-0-3=octal&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&value0-0-4=octal&short_desc_type=allwordssubstr&field0-0-2=alias&value0-0-1=octal&type0-0-0=substring&value0-0-6=octal&value0-0-0=octal&component=JavaScript%20Engine&product=Core&type0-0-2=substring

Indeed we made bugs for our users in the course of implementing and 
finalizing ES5. Here's a particularly time-killing exercise:

https://bugzilla.mozilla.org/show_bug.cgi?id=601262
>
> I don't think people writing non-strict code as their default for 
> node.js is a problem solved by changing strict mode.

Harmony is based on strict mode. V8 is implementing Harmony proposals 
for ES.next. The recent version-free opt-in thinking in concert with 
these facts suggest Node.js people will be writing ES.next code at some 
point. Will octal permission literals work then? It's a small point but 
I say they ought to.

> 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.

This part I agree with. Strict mode did some good things we like (all 
the early errors, basically). The runtime meaning shifts and their 
implications for performance (at least, without new optimization effort 
on the part of implementors, who face little incentive without adoption 
-- which won't be forthcoming without performance) were not good.

/be
>
> /L
>
>
> Brendan Eich <mailto:brendan at mozilla.com>
> January 12, 2012 10:47 PM
> 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120113/a38a1102/attachment.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/20120113/a38a1102/attachment.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/20120113/a38a1102/attachment-0001.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/20120113/a38a1102/attachment-0002.jpg>


More information about the es-discuss mailing list