On Thu, Dec 6, 2012 at 2:41 PM, Jussi Kalliokoski < [email protected]> wrote:
> On Thu, Dec 6, 2012 at 8:44 PM, Rick Waldron <[email protected]>wrote: > >> values() returns an iterable of the values in the array. Array, Map and >> Set will receive all three: keys(), values(), entries(). Feel free to start >> a new thread if you want to argue about iterator protocol. >> > > Yes, I apologized for that mistake already, I remembered incorrectly. I > don't have a want to argue, just like I'm sure you don't. > All this misses your important "pears and oranges" point. These are not mutable APIs, which is a key distinction. The sort method would have been a good example of a mutable API returning `this`. But it's not exactly a model to emulate. > I'm absolutely not dodging the question, I answered this in a previous >> message, much earlier. Cascade/monocle/mustache is not a replacement here. >> > > That wasn't the question I asked. Cascade/monocle/mustache aren't even > ready yet, and are hence in no way an indication that chaining cannot be > made a language-side construct. I believe it can and will, and at that > point, returning this becomes completely meaningless. But (I don't see) how > can you fix this on the language syntax side: > > var obj = { > foo: bar, > baz: taz > } > set.add(obj) > return set > > instead of simply: > > return set.add({ > foo: bar, > baz: taz > }) > > >>> What I mean is that the not all functions in an API can return `this` >>> anyway (like getters), so it's inconsistent. After all, it's not a very >>> useful API if you can just set but not get. >>> >> >> That's exactly my point. The set/add API return this, allowing >> post-mutation operations to be called: such as get or any of the examples >> I've given throughout this thread. >> > > What? I'm really sorry, but I can't understand how what I said leads to > your point. But I bet we're both wasting our time with this part, so it's > probably best to just leave it. > > >> No one said anything about applying return this to "everything that's not >> a getter". That was exactly what the criteria we have consensus on defines. >> It's in the meeting notes for Nov. 29. >> > > Sorry, about that, the meeting notes (in the part "Cascading this > returns") just say: > > "Supporting agreement" > "(Discussion to determine a criteria for making this API specification > distinction)" > "Consensus... with the criteria that these methods are not simply a set of > uncoordinated side effects that happen to have a receiver in common, but a > set of coordinated side effects on a specific receiver and providing access > to the target object post-mutation." > > With no reference to the logic behind the conclusion ("these methods are > not simply a set of uncoordinated side effects that happen to have a > receiver in common"). I fail to see how .set()/.add() are a special case. > Am I missing something? > > Please read everything I've written so far, it's not fair to make me >> constantly repeat myself in this thread. >> > > I agree, and I'm sorry, but I have, at least everything on this thread, > those referred to and those that have seemed related. I'm doing my best, > but I'm afraid I can't keep up with every thread in my inbox, and I don't > think it's a good reason for me not to contribute at all. > > Of course I could've shown it as you have here, but I made examples where >> the intention was to match the preceding examples illustrated in the gist. >> > > Fair enough, but I fail to see the convenience in your examples. > > Why would you need to stuff everything in one line? >>> >> >> As evidenced several times throughout this thread, the pattern is widely >> implemented in the most commonly used library APIs, so I guess the answer >> is "The kids love it". >> > But which kids? There certainly appears to be quite a sampling bias in your survey -- I didn't see a single actual *collection* library. Sampling their choices would be the most helpful, not *what the kids are doing*. Plus there are other alternatives I haven't seen discussed, so the design space has barely been explored. For instance buckets [1] is a nice example of a collection library that takes an approach more reminiscent of javascript's existing array mutation methods -- its add method returns `true` if the item was newly created or `false` if it was already present in the collection -- a lot like javascript's delete operator. I'm not necessarily advocating for this, just offering up the idea that any survey should look closer at existing collection libraries to get a better feel for the full design space. [1] https://github.com/mauriciosantos/buckets > document.write() is widely implemented too, doesn't make it good or worth > repeating. > That's a low blow :) > This way it's more version control friendly as well, since those two >>> lines of code have actually nothing to do with each other, aside from >>> sharing dealing with the same object. Why do you want to get all of those >>> things from .set()/.add(), methods which have nothing to do with what >>> you're getting at? >>> >> >> You could just as easily have them on separate lines, but in cases where >> it might be desirable to immediately operate on the result of the mutation, >> chaining the next method call has the net appearance of a single tasks (if >> that's how a programmer so chooses to express their program). >> > > So it's taste, rather than convenience? > Is there really a difference? Personally I believe only immutable APIs should ever return `this`, since there's real value there. Mutable APIs should punish you, even if only slightly. But that's just my taste.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
