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

Rick Waldron waldron.rick at gmail.com
Tue Dec 4 11:34:48 PST 2012


On Tue, Dec 4, 2012 at 1:55 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> 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
>

My dream would be that push returned the array, so that I could immediately
operate on that array.



> 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/
>

No, this returns a new jQuery object (ie. the array-like jQuery collection
of elements) that is the initial object merged with the newly added item
(pushed onto the end) and filtered for uniqueness:

var elems = jQuery("body");

elems.add("div:first");
// [ body, div ]

elems.add("div:first");
// [ body, div ] <-- "looks" the same

The creation of a new jQuery object (via pushStack) is a legacy
mechanism—however the observable result is effectively the same as
set.add(something) => set, as elements.add(element) => newElements (as far
as any web developer's program semantics are concerned).



>
>
> So developers prefer the added/set value,
>

Three vocal posters to a mailing list do not represent "developers" as a
whole. There were more web developer originating committee members that
supported returning this. (I hate playing this game, it's not fun)



> this is why I have asked who/why you decided for that, IMHO pointless,
> `this` as default return.
>

I answered this directly in the first response. I proposed it, based on a
wealth of existing library code used on the web and the proposal was met
with significant support from within the committee.


> 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
>

All due respect, but JavaScript is not Smalltalk. Let's standardize on our
own established patterns.

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121204/62b30457/attachment.html>


More information about the es-discuss mailing list