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

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Dec 4 11:46:28 PST 2012


for develoeprs I meant jQuery users too, being one of th emost popular API
out there.

What I meant with jQuery#add method is that last thing added is the one
returned, it does nto return the initial object, it returns the new result
out of a merge but this is not the initial this, this is a new thing with
latest added thing in.

Br


On Tue, Dec 4, 2012 at 11:34 AM, Rick Waldron <waldron.rick at gmail.com>wrote:

>
>
>
> 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/112146cd/attachment.html>


More information about the es-discuss mailing list