On Dec 3, 2012, at 2:53 PM, Nathan Wall wrote: > I'm not a person of influence, but as a JS developer, I agree with Andrea on > this. I think Map#set() should return the value. I would expect the same > behavior as obj[key] = value. I find Andrea's use case (m.get(k) || m.set(k, > v)) more compelling than the method chaining possibilities. >
It's also worth noting that in Smalltalk the at:put: methods that roughly correspond to ES6 set methods always return the value that is stored. This is in a language where the default behavior is to return the "this value" of a method. Smalltalk programmers use "this chaining" a lot, but in the case of at:put: the stored value is deemed the more interesting value to return. In reality it depends upon your use case. If you want to do this chaining then you want the this value as the result. If you want to pass a computed stored value on to something else, you want the stored value returned. You can't have it both ways. Smalltalk had another way to do this chaining that ignores the actual return value, so returning the stored value was an obvious design choice for it. It's less clear which is the best choice for JS. Allen > > Nathan > > > Date: Mon, 3 Dec 2012 14:21:24 -0800 > Subject: Re: (Map|Set|WeakMap)#set() returns `this` ? > From: [email protected] > To: [email protected] > CC: [email protected] > > IMHO, a set(key, value) should return the value as it is when you address a > value > > var o = m.get(k) || m.set(k, v); // o === v > > // equivalent of > > var o = m[k] || (m[k] = v); // o === v > > a set with a key that returns `this` is a non case so almost as useless as > the void return is. > > Usefulness comes with use cases ... except this jQuery chainability thingy > that works fine for jQuery structure ( an ArrayLike Collection ) who asked > for map.set(k0, v0).set(k1, v1).set(k2, v2) ? Or even map.set(k0,v0).get(k1) > ? what are use cases for this? > > I am honestly curious about them because I cannot think a single one ... > specially with the Set > > s.add(k0).add(k1).add(k2) ... this code looks weird inlined like this ... > > Thanks for your patience > > > > > > > > On Mon, Dec 3, 2012 at 2:04 PM, Rick Waldron <[email protected]> wrote: > > > > On Mon, Dec 3, 2012 at 4:28 PM, Andrea Giammarchi > <[email protected]> wrote: > I wonder what was the use case that convinced TC39 to return `this` with > these methods. > > Assuming you read the notes, I proposed the agenda item based on the best > practice of ensuring meaningful returns, and in the case of mutation methods, > |this| is a meaningful return. > > > Accordingly, this will never work: > var query = map.has('queried') ? map.get('queried') : map.set('queried', > $('myquery')); > > Previously, map.set() had a useless void return... > > > > And it will be something like: > var query = map.has('queried') ? map.get('queried') : map.set('queried', > $('myquery')).get('queried'); > > which is ugly and I don't really understand where map.set(k0, v0).set(k1, > v1).set(k2, v2) could be useful. > > Accessing the object post-mutation allows for more expressive use of the API. > > > Rick > > > Thanks for clarifications ( a use case would be already good ) > > br > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > > > _______________________________________________ es-discuss mailing list > [email protected] https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
