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

[Herby Vojčík]

Hm, it's hard with those precedents already existing.

I was not talking about dropping 0x (or officially obsoleting it), it is 
really strong pattern. I was just advocating, since they are not in strict 
mode (0x is, so it's ok), not adding any more 0o and 0b, adding 8r, 2r and 
generally any radix up to 36r instead.

But again, if 0o and 0b wins everywhere else... I can't say myself which is 
better... I'd still lean gently for r, but those precedents made it weaker.

Herby

-----Pôvodná správa----- 
From: Brendan Eich
Sent: Thursday, January 12, 2012 7:59 PM
To: Herby Vojčík
Cc: Axel Rauschmayer ; es-discuss
Subject: Re: Octal literals have their uses (you Unix haters skip this one)

Maybe -- the precedent from Python and Ruby for 0o377 is strong than 
Smalltalk precedent at this point.

What's more, you seem to want a generalization to any radix, as if all 
radixes are useful or even used. JS already has 0x for hex, which is much 
more useful than octal. After octal would come binary, and CoffeeScript, 
Python and Ruby precedents want 0b111. After that, there really aren't any 
commonly-used (or all that useful, apart from obfuscation exercises) 
radixes.

So we have a 0x precedent in JS, from C (by way of Java). We have 
nearby/upstream scripting language precedents with Python, Ruby, and 
CoffeeScript, for 0o and 0b. We have zero practical use-cases for arbitrary 
radixes. Furthermore we won't see people migrate from 0x to 16r, ever.

So all of this says to me we should avoid generalizing for its own sake, and 
follow nearby precedents first.

/be



Herby Vojčík
January 12, 2012 10:48 AM
Would it be hard to bring in Smalltalkish 8r377? Another (and similar to 0)
special char for specific radix - well, wouldn’t it be better to include a
letter for all radixes (CoffeeScript can maybe take it on, too).

Herby

-----Pôvodná správa----- From: Brendan Eich
Sent: Thursday, January 12, 2012 7:21 PM
To: Axel Rauschmayer
Cc: es-discuss
Subject: Re: Octal literals have their uses (you Unix haters skip this one)

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.

And performance can be an issue, but the readability and writability
problems are enough.

/be



Axel Rauschmayer
January 12, 2012 10:10 AM
parseInt("377", 8)? Assuming that performance isn’t an issue.









_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Brendan Eich
January 12, 2012 10:21 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.

And performance can be an issue, but the readability and writability 
problems are enough.

/be


_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Axel Rauschmayer
January 12, 2012 10:10 AM
parseInt("377", 8)? Assuming that performance isn’t an issue.



Brendan Eich
January 12, 2012 10:01 AM
See https://github.com/jashkenas/coffee-script/pull/2021 -- strict mode 
support in CoffeeScript exposes a valid use-case, Unix-flavor file 
permissions (mode bits we used to say). Node.js APIs really want users to 
call with literals such as 0644. Strict mode says no way.

For now CoffeeScript probably will support 0o644 and translate to hex or 
decimal literals to dodge the strict error. But ES5 still has octal in Annex 
B, and AFAIK octal support is still required for web compatibility.

Strict mode is not being adopted widely enough, certainly not in node.js 
code, to kill octal literals. Killing octal literals is user-hostile when it 
comes to Unix permissions. So I think we should stop tilting at a friendly 
windmill, and either support octal literals (but not noctal -- no 08 or 09), 
or support 0o377 etc. as CoffeeScript looks like it will do.

Some may object to lowercase o as prefix. It's clear enough in all fonts, 
but if we allow uppercase O too, then some might fear user confusion with 0 
used instead of O. But if we support 0o377 and 0O377, we can continue to 
reject (in strict mode and therefore in Harmony) 00377. Anyway, there's no 
homograph phishing attack threat as with URLs.

If the CoffeeScript experiment with 0o prefixes for octal works out, I think 
we should adopt that prefix. But at this point I wouldn't be surprised to 
see retention of 0377 support be demanded by CoffeeScript/Node.js users, and 
they have a point.

CoffeeScript can certainly compile this to a strict hex or decimal literal 
to dodge the error, but then JS/Node.js is at a loss, and for no good 
reason. In this case I will argue for supporting octal literals in strict 
mode.

/be

_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss