At the last EcmaScript meeting, I proposed the const function notation
seen at http://wiki.ecmascript.org/doku.php?id=strawman:const_functions.
Someone -- my apologies, I forget who -- suggested that const functions
would make the old never-implemented ES3 joining optimization safe. (If you
don't
http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar
Of the three straw contenders for this niche, my preference order continues
to be
* Traits
* Classes as Sugar
* Enhanced Object Literals
But since Traits seems to be blocked from advancing, I have now finally put
the Classes as
On Sun, Sep 5, 2010 at 7:19 AM, Mark S. Miller erig...@google.com wrote:
At the last EcmaScript meeting, I proposed the const function notation
seen at http://wiki.ecmascript.org/doku.php?id=strawman:const_functions.
Someone -- my apologies, I forget who -- suggested that const functions
http://wiki.ecmascript.org/doku.php?id=strawman:egal
I have previously taken the position on this list that we should not add a
third equality construct to JavaScript. However, it is relevant to several
other strawmen that are likely to advance -- hasCode, Maps and Sets. Also,
its absence
On Sep 5, 2010, at 7:40 AM, Mark S. Miller wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:egal
I have previously taken the position on this list that we should not add a
third equality construct to JavaScript. However, it is relevant to several
other strawmen that are likely to
I've had the need to read and save an array element just before updating it to
a new value:
oldValue= array[index];
array[index]= newValue;
doSomethingWith(oldValue)
If instead I had had to post-increment/decrement it I could have written just :
doSomethingWith( array[index]++ );
which is
On Sep 5, 2010, at 8:28 AM, Maciej Stachowiak wrote:
Other possibilities:
- Make Object.hashcode pair with === or == instead of Object.eq: formally
impossible, because neither is actually an equivalence relation. Less
formally, possible at the cost of making it impossible to use NaN as a
On Sun, Sep 5, 2010 at 3:28 PM, Brendan Eich bren...@mozilla.com wrote:
The eq name is freakishly short, which might up the odds of it not
colliding with existing user-level extensions to Object
http://api.jquery.com/eq/
- Sam Ruby
___
es-discuss
On Sep 5, 2010, at 12:28 PM, Brendan Eich wrote:
On Sep 5, 2010, at 8:28 AM, Maciej Stachowiak wrote:
Other possibilities:
- Make Object.hashcode pair with === or == instead of Object.eq: formally
impossible, because neither is actually an equivalence relation. Less
formally, possible
On Sep 5, 2010, at 1:08 PM, Sam Ruby wrote:
On Sun, Sep 5, 2010 at 3:28 PM, Brendan Eich bren...@mozilla.com wrote:
The eq name is freakishly short, which might up the odds of it not
colliding with existing user-level extensions to Object
http://api.jquery.com/eq/
I don't think this
I would propose to name it Object.equals() as opposed to the unnecessary short
eq(), which does not seem right next to unnecessarily verbose function names
such as Object.getOwnPropertyDescriptor()
Juerg
On 5 Sep 2010, at 15:40, Mark S. Miller wrote:
On Sep 5, 2010, at 5:49 PM, Jürg Lehni wrote:
I would propose to name it Object.equals() as opposed to the unnecessary
short eq(), which does not seem right next to unnecessarily verbose function
names such as Object.getOwnPropertyDescriptor()
equals or equal would be ok by me. eq is in
Snipping together several emails:
Of course not. But it does allow these to be frozen. SES makes use of that to
freeze them (after cleaning them up) as the last step of its initialization
http://code.google.com/p/es-lab/source/browse/trunk/src/ses/initSES.js#557.
So why not allow the
On Sep 5, 2010, at 5:33 PM, Maciej Stachowiak wrote:
On Sep 5, 2010, at 1:08 PM, Sam Ruby wrote:
On Sun, Sep 5, 2010 at 3:28 PM, Brendan Eich bren...@mozilla.com wrote:
The eq name is freakishly short, which might up the odds of it not
colliding with existing user-level extensions to
14 matches
Mail list logo
