(Map|Set|WeakMap)#set() returns `this` ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Dec 4 10:55:59 PST 2012


clear for "us" ( Developers ) but also clear semantically speaking.

As it is proposed now it looks like if a "setter" returns something which
is the context while, again, when you set 99% of the time you don't want to
do it separately in order to have that value back.

You don't want to create another reference and you want "set" to do what
you expect: set

When you set, you implicitly point to the set value as it is for:

return some.prop = someValue;

var setValue = (obj.prop = someValue);

var deflt = obj.prop || (obj.prop = value);

this.doStuff(
  this.hasOwnProperty(key) ?
    this[key] : this[key] = computateThingOnce()
);

And so on ... I think there are tons of use cases more frequent and used
than this.set(key, value).get(key) ... I wonder how many times you have
dreamed about var value = arr.push(some[data]); too and going back to
jQuery style, when you add something, the equivalent of set or add for Set,
you point to the subset you have added, not the initial collection, isn't
it ...
http://api.jquery.com/add/

So developers prefer the added/set value, this is why I have asked who/why
you decided for that, IMHO pointless, `this` as default return.

It just does not look right but sure it might have some use case ... the
fact I had to think about them means already these are more rare than a
classic returned value.

+1 Smalltalk choice then




On Tue, Dec 4, 2012 at 10:43 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> 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: andrea.giammarchi at gmail.com
> To: waldron.rick at gmail.com
> CC: es-discuss at mozilla.org
>
> 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 <waldron.rick at gmail.com>
> wrote:
>
>
>
>
> On Mon, Dec 3, 2012 at 4:28 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> _______________________________________________ es-discuss mailing list
> es-discuss at mozilla.org https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121204/adbe6266/attachment-0001.html>


More information about the es-discuss mailing list