Can the slides from the last TC39 meeting be downloaded somewhere? From Rick’s
notes, they looked interesting.
Thanks!
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss
At the last TC39 meeting, it was agreed tothat the set/add methods would return
the collection that to which something is being added.
This supports code patterns like:
someMap.set(key1,value1).set(key2,value3);
In making this change to the spec. I noticed several other methods that could
On Sun, Jan 13, 2013 at 4:44 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
At the last TC39 meeting, it was agreed tothat the set/add methods would
return the collection that to which something is being added.
This supports code patterns like:
someMap.set(key1,value1).set(key2,value3);
delete is supposed to return whether the item was in the collection to
delete or not, which otherwise would require using has to check for before
deleting. I don't know how useful the functionality is, but wanted to note
it since it'd be lost with this change. Chaining `clear` is an easy
On Sun, Jan 13, 2013 at 5:14 PM, Brandon Benvie
bran...@brandonbenvie.com wrote:
delete is supposed to return whether the item was in the collection to
delete or not, which otherwise would require using has to check for before
deleting. I don't know how useful the functionality is, but wanted
Personally, I've never used the result of `collection.delete` for anything
and I'm not confident that the use case exists. I just wanted to note what
was being lost by changing the return value.
On Sun, Jan 13, 2013 at 8:21 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Sun, Jan 13, 2013 at
Another possibility is to let map.delete(key) return the mapped value (a bit
like Array.prototype.pop()). But I’m not sure how useful that is, either.
On Jan 14, 2013, at 2:23 , Brandon Benvie bran...@brandonbenvie.com wrote:
Personally, I've never used the result of `collection.delete` for
Since then, due to issues pointed out here on es-discuss, I withdrew
my consensus from this decision.
See also
https://mail.mozilla.org/pipermail/es-discuss/2012-December/026971.html
where Andreas states the issue more clearly than I did.
On Sun, Jan 13, 2013 at 4:44 PM, Allen Wirfs-Brock
My reversal was posted at
https://mail.mozilla.org/pipermail/es-discuss/2012-December/026932.html.
Thanks there to Jussi Kalliokoski for also clearing up this issue.
On Sun, Jan 13, 2013 at 6:45 PM, Mark S. Miller erig...@google.com wrote:
Since then, due to issues pointed out here on
In that case, it would be really nice for .set to return the value so these
work:
return map.has(key) ? map.get(key) : map.set(key, val);
and
return map.get(key) || map.set(key, val);
On Sunday, January 13, 2013, Mark S. Miller wrote:
My reversal was posted at
On Jan 13, 2013, at 5:14 PM, Brandon Benvie wrote:
delete is supposed to return whether the item was in the collection to delete
or not, which otherwise would require using has to check for before deleting.
I don't know how useful the functionality is, but wanted to note it since
it'd be
+1 since that was my initial (forever dreamed) proposed idea :-)
On Sun, Jan 13, 2013 at 6:53 PM, Brandon Benvie
bran...@brandonbenvie.comwrote:
In that case, it would be really nice for .set to return the value so
these work:
return map.has(key) ? map.get(key) : map.set(key, val);
On Jan 13, 2013, at 6:47 PM, Mark S. Miller wrote:
My reversal was posted at
https://mail.mozilla.org/pipermail/es-discuss/2012-December/026932.html.
Thanks there to Jussi Kalliokoski for also clearing up this issue.
Well, I don't agree with Jussi's contention that it is an anti-parttern.
Allen the cascading thing is usually leading to think everything is
cascading and there will always been cases where methods will break that
cascading thing ...
In these case we have .has(key) able to break the keep going and do stuff
with the instance.
In a direction where monocle mustaches has
Here is a link to a documentatin for the weak map based solution that Kris
mentioned:
https://addons.mozilla.org/en-US/developers/docs/sdk/latest/modules/sdk/core/namespace.html
We find it invaluable and use for storing private field. Inheritance works,
but we did not found that feature all that
and that was ... U_U
var anotherValue = map.{
delete(key);
set(other, value);
get(another);
};
On Sun, Jan 13, 2013 at 8:18 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
var another = map.{
delete(key);
set(other, value)
get(another);
};
On Sunday, January 13, 2013, Andrea Giammarchi wrote:
and that was ... U_U
var anotherValue = map.{
delete(key);
set(other, value);
get(another);
};
The cascade operator was too late for ES6.
I still strongly agree with returning the collection post-mutation and I
think Allen's
On Jan 13, 2013, at 8:18 PM, Andrea Giammarchi wrote:
Allen the cascading thing is usually leading to think everything is cascading
and there will always been cases where methods will break that cascading
thing ...
In these case we have .has(key) able to break the keep going and do stuff
Allen Wirfs-Brock wrote:
if we excluded the cascade result at the API design level then we are
making it impossible for those who like the cascade pattern from using it.
The biggest thing I got out of the discussion Mark linked to is that the
cascade pattern is potentially supportable with an
precisely and agreed 100%, this was my point again ... we know **now** that
monocle mustache is good and we would like to change last minute some ES6
collection in a redundant way, accordingly with what we know already is
going to be good for ES6 ?
As so, if returning `this` cannot be
I have a couple of questions:
1. Isn't chaining now considered less-good style compared to a newer
jQuery API that takes an object literal full of properties to add?
2. Is there any precedent for delete-chaining in any library?
/be
___
es-discuss
For what I can tell
1. when obj.{...} will be available in coffeeScript and transpilers
nobody will ever care about the return this 2004 style like API (long
glory to this API)
2. never seen delete used chained but I've seen .remove(item) used
chained, if that's a valid metaphor/equivalent
Can the slides from the last TC39 meeting be downloaded somewhere? From
Rick's notes, they looked interesting.
Sure thing - I've posted the slides here: http://sdrv.ms/W21q9e. These
slides were talking points, Rick's notes contain the broader discussion at the
meeting here:
23 matches
Mail list logo
