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

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Dec 5 08:52:34 PST 2012


and as last argument from my side, I **LOVE** the DOM appendChild method
and I use it a lot

var div = document.body.appendChild(document.createElement("div"));

This is the best example of "returning the value" I could think and the one
I use the most on daily basis.

Br


On Wed, Dec 5, 2012 at 8:37 AM, Jussi Kalliokoski <
jussi.kalliokoski at gmail.com> wrote:

> On Wed, Dec 5, 2012 at 6:29 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> For what is worth it , I don't believe "everyone does it like that" has
>> ever been a valid argument. Maybe everyone simply copied a pattern from
>> jQuery without even thinking if it was needed or it was the best.
>>
>> Br
>>
>
> Agreed. You don't make a band that makes crappy music because most other
> bands do too. You don't jump in the well if I do. We don't have to make bad
> API decisions because the cows have paved a path to the butcher's. It's not
> ignoring the norm, we acknowledge it and make our choices with that
> knowledge, but we don't necessarily have to follow the norm.
>
> Cheers,
> Jussi
>
>
>> On Wednesday, December 5, 2012, Rick Waldron wrote:
>>
>>>
>>>
>>>
>>> On Wed, Dec 5, 2012 at 10:06 AM, Nathan Wall <nathan.wall at live.com>wrote:
>>>
>>>> > Date: Tue, 4 Dec 2012 11:03:57 -0800
>>>> > From: brendan at mozilla.org
>>>>
>>>> > Subject: Re: (Map|Set|WeakMap)#set() returns `this` ?
>>>> >
>>>> > Allen Wirfs-Brock wrote:
>>>> > > It's less clear which is the best choice for JS.
>>>> >
>>>> > Cascading wants its own special form, e.g., Dave's
>>>> > mustache-repurposed proposal at
>>>> >
>>>> > https://blog.mozilla.org/dherman/2011/12/01/now-thats-a-nice-stache/
>>>> >
>>>> > so one can write cascades without having to be sure the methods
>>>> involved
>>>> > follow an unchecked |this|-returning convention.
>>>>
>>>>
>>>> I really like this possibility. Is there any way of the
>>>> monocle-mustache making it into ... say, ES7?
>>>>
>>>> If so, it would seem wrong to ever return `this`.  Sounds like you get
>>>> the best of both worlds to me!
>>>>
>>>
>>> Yes, monocle-mustache is very cool, especially Dave's proposed version
>>> here, but this:
>>>
>>> obj.{
>>>    prop = "val"
>>> };
>>>
>>> ...has received negative feedback, because developers want colon, not
>>> equal, but colon is to "define" as equal is to "assign".
>>>
>>> eg. What does this do?
>>>
>>> elem.{
>>>    innerHTML: "<p>paragraph</p>"
>>> };
>>>
>>> Most developers would naturally assume that this sets elem.innerHTML
>>> to "<p>paragraph</p>", but it actually results in a [[DefineOwnProperty]]
>>> of innerHTML with {[[Value]]: "<p>paragraph</p>" , [[Writable]]: true,
>>> [[Enumerable]]: true, [[Configurable]]: true}, which would blow away the
>>> accessor descriptor that was previously defined for elem.innerHTML (ie. the
>>> one that would convert "<p>paragraph</p>" to a node and insert it into the
>>> DOM. So the obvious choice is to use "=" instead of ":" because it
>>> correctly connotes the assignment behaviour—except that developers
>>> complained about that when we evangelized the possibility.
>>>
>>> Monocle-mustache is simply not a replacement for return this because
>>> chaining mutation methods is not the sole use case. Please review the use
>>> cases I provided earlier in the thread.
>>>
>>> There is simply too much real world evidence (widely adopted libraries
>>> (web) and modules (node)) in support of return-this-from-mutation-method to
>>> ignore, or now go back on, a base criteria for including the pattern in
>>> newly designed built-in object APIs.
>>>
>>> Rick
>>>
>>>
>>
>> _______________________________________________
>> 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/20121205/c7819dac/attachment.html>


More information about the es-discuss mailing list