Wouldn't it be better to namespace these bit-operators in a different module?
Bit.clz() perhaps? The Math module is getting a bit crowded.
On Sat, 03 Mar 2012 23:21:11 -0800, Brendan Eich bren...@mozilla.org wrote:
I'm open to clz/clo. The names perhaps need to be less cryptic... or not.
Bit.clz() sounds just as good to me. I don't know if they need to be less
cryptic, if someone doesn't know the abbreviation, it is highly likely
(s)he doesn't need the functions either. :)
On Sun, Mar 4, 2012 at 10:01 AM, Tomas Carnecky t...@caurea.org wrote:
Wouldn't it be better to namespace
Maybe make it generic? Although that might not be very important for
the case of counting leading zeroes or ones.
I'd love a function for getting n consecutive bits (to left or
right..) from number x starting from the nth bith (from the left or
right) as a single number as if the lsb was 1. You
I think it's worse to have combined characters, like #@ or ^ than it is
to have same character repeated... ^^ looks nice to me (also points up,
which may create a little analogy to the UML generalization), but ok.
Two same characters are more easily spotted, imho, and they are more
easily
looks like a bitwise operator and if ** was to be an operator, I'd
prefer it to be a shorhand for Math.pow.
Sent from my smartphone.
On Mar 4, 2012 11:21 AM, Herby Vojčík he...@mailbox.sk wrote:
I think it's worse to have combined characters, like #@ or ^ than it is
to have same character
I'm not sure I understood correctly, but... I think for the sake of this
being a useful performance optimization, it shouldn't have any overloads /
optional arguments, maybe a separate function for that is a better.
Also, while we are adding things to the Bit namespace, I'm not sure if
ctz/cto
Can we really add a Bit namespace without breaking the web? Maybe
Math.Bit if we really want a bitwise operation namespace?
clz, clo, the names are cryptic but so are their applications -- so I think
it's a good fit. zLen and oLen might also make good names.
These could be handy for other
I agree that there are useful functions when doing bit level decoding. Luke
has been championing the Math function additions for ES.next so he should
probably be the one to look at these specifically.
I assume that this function would apply ToInt32 to its argument. In other
words, it is
On Sun, Mar 4, 2012 at 4:45 PM, Wes Garland w...@page.ca wrote:
Can we really add a Bit namespace without breaking the web? Maybe
Math.Bit if we really want a bitwise operation namespace?
clz, clo, the names are cryptic but so are their applications -- so I
think it's a good fit. zLen and
On Sat, Mar 3, 2012 at 11:17 PM, Brendan Eich bren...@mozilla.org wrote:
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
The problem with | and friends is that the common mental association
with these symbols do
On Sun, Mar 4, 2012 at 6:44 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
I agree that there are useful functions when doing bit level decoding.
Luke has been championing the Math function additions for ES.next so he
should probably be the one to look at these specifically.
I assume
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
a while back, and we discussed alternative contextual keywords. Grawlix
appears to result in (a) strong
John J Barton wrote:
On Sat, Mar 3, 2012 at 11:17 PM, Brendan Eichbren...@mozilla.org wrote:
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
The problem with| and friends is that the common mental association
I'm not a native english speaker and I think both are the same when
learning.
Words allow people not knowing JS to kind of understand.
Symbols are shorter to write and are easier to spot when looking at code.
I'd prefer a symbol but I'm sure others would prefer a word (that's why
some operators
Allen Wirfs-Brock wrote:
On Mar 4, 2012, at 9:18 AM, Herby Vojčík wrote:
P.P.S.: I don't know what 'beget' means (I know I can find it,
just to illustrate it's not a commonly known word).
If you don't know the word, is it easier to learn a new symbol (eg
|) or a new keyword (eg beget)?
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
+1. Using a symbol like an arrow makes a lot of sense when there is a clear
directionality in the operation (e.g. chasing a chain of pointers in C), but
the lack
I worry mainly about terminology. Wouldn’t “beget” introduce a new term for
specifying “the prototype of”? Learning a new word in and of itself has never
been a problem for me, especially when it goes along with a new concept.
More possibilities (I know some of these have been suggested before,
On 03/04/2012 02:14 PM, Allen Wirfs-Brock wrote:
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? [snip...]
I have two significant sized code samples that differ only in the use
of beget in place of |
Compare:
On 03/04/2012 03:38 PM, Gavin Barraclough wrote:
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
+1. Using a symbol like an arrow makes a lot of sense when there is a
clear directionality in the operation (e.g.
Experiment: I’ve written down the proposals that have been made so far, to
reduce the circles we are going in. Let me know of any corrections or additions
I should make.
https://docs.google.com/spreadsheet/ccc?key=0Apu8J_NsHwGGdHRtTThMZWdocy1ad2ZCaktpVVdPWEE
On Mar 4, 2012, at 18:30 , Allen
On Mar 3, 2012, at 3:24 PM, Dean Landolt wrote:
...
Does it have to be ascii? The growlix space of unicode is vast:
https://plus.google.com/109925364564856140495/posts
Reaching into the depths of unicode was roundly panned during the function
shorthand debates but Allen's reach for ◁ is
It seems very strange to me to have a clz and getOwnPropertyDescriptor
coexist as naming choices in the same language. I have taken to doing
var gopd = Object.getOwnPropertyDescriptor;
early in many of my source files. I think this is better than standardizing
an obscure acronym. This way,
Please don't take my message as an endorsement that these operations should
be standardized at all, under any name. I do not yet have an opinion about
that.
On Sun, Mar 4, 2012 at 12:22 PM, Mark S. Miller erig...@google.com wrote:
It seems very strange to me to have a clz and
On Sun, 04 Mar 2012 20:36:31 +0100, Axel Rauschmayer a...@rauschma.de
wrote:
Experiment: I’ve written down the proposals that have been made so far,
to reduce the circles we are going in. Let me know of any corrections or
additions I should make.
This list is really useful!
One more to add:
:
... has also been proposed
Rick
On Sun, Mar 4, 2012 at 2:36 PM, Axel Rauschmayer a...@rauschma.de wrote:
Experiment: I’ve written down the proposals that have been made so far, to
reduce the circles we are going in. Let me know of any
http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects
Quote: “We could extend this to allow the passing of an optional visibility
flag (defaults to false) to create(). [...] This would be useful for e.g.
modular monkey-patching.”
Really true? Would the ability to see a uniquely
Le 03/03/2012 12:26, Axel Rauschmayer a écrit :
http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects
Quote: “We could extend this to allow the passing of an optional visibility
flag (defaults to false) to create(). [...] This would be useful for e.g.
modular monkey-patching.”
It's worth noting that even high performance languages like C don't have clz,
etc builtin - people still have to drop down to assembly to implement them. If
you really wanted to you could just use the standard bit fiddling techniques,
and if necessary JS engines would start optimising those
A friend commented, all the symbol forms are difficult to speak over a
phone. The operator will need a common pronounceable name, so why not use
that instead of a symbol.
On Sun, Mar 4, 2012 at 1:28 PM, Rick Waldron waldron.r...@gmail.com wrote:
Allen,
On Sun, Mar 4, 2012 at 12:14 PM, Allen
Hello,
I feel uneasy about this in | proposal:
If the LHS operand has a property named prototype and the RHS
operand is a function expression then the [[Prototype]] of the
function object is set to the LHS object and the prototype property
of the new function is set to a new object whose
On Sun, Mar 4, 2012 at 4:57 PM, felix feli...@gmail.com wrote:
A friend commented, all the symbol forms are difficult to speak over a
phone. The operator will need a common pronounceable name, so why not use
that instead of a symbol.
On Sun, Mar 4, 2012 at 11:50 PM, Oliver Hunt oli...@apple.com wrote:
It's worth noting that even high performance languages like C don't have
clz, etc builtin - people still have to drop down to assembly to implement
them. If you really wanted to you could just use the standard bit fiddling
Make test cases where the bit-fiddly technique is too slow and file bugs on the
various bug trackers: bugs.mozilla.org bugs.webkit.org and somewhere on
chromium.org :D
It's possible (given the relative infrequency of bitops) that most engines are
still doing stuff that's really dumb -- i know
On Mar 4, 2012, at 1:59 PM, Herby Vojčík wrote:
Hello,
I feel uneasy about this in | proposal:
If the LHS operand has a property named prototype and the RHS
operand is a function expression then the [[Prototype]] of the
function object is set to the LHS object and the prototype property
that or prototypeof?
On Sun, Mar 4, 2012 at 5:29 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Sun, Mar 4, 2012 at 4:57 PM, felix feli...@gmail.com wrote:
A friend commented, all the symbol forms are difficult to speak over a
phone. The operator will need a common pronounceable name,
prototype for is also referred to as:
- prototype operator
- proto operator
- ProtoLiteral
Rick
On Sun, Mar 4, 2012 at 10:32 PM, Kevin Smith khs4...@gmail.com wrote:
that or prototypeof?
On Sun, Mar 4, 2012 at 5:29 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Sun, Mar 4, 2012 at
36 matches
Mail list logo
