On Thu, Dec 6, 2012 at 8:25 PM, Jussi Kalliokoski < jussi.kallioko...@gmail.com> wrote:
> On Thu, Dec 6, 2012 at 7:32 PM, Rick Waldron <waldron.r...@gmail.com>wrote: > >> Array.prototype.map and Array.prototype.filter return newly created >> arrays and as such, are chainable (and will have the same benefits as I >> described above) >> >> // map and return a fresh iterable of values >> array.map( v => ... ).values() >> >> // map and return a fresh iterable of entries (index/value pairs) >> array.filter( v => ... ).entries() >> > > Of course, but that's pears and apples, .set() doesn't create a new > instance. And btw, that .values() is redundant. > Wait, sorry about that, wrote before I investigated. > > >> >>> I agree with you, fear-driven design is bad. But don't you agree that if >>> there's chaining, it's better done at language level rather than having all >>> APIs be polluted by `this` returns? >>> >> >> Who said all APIs would return `this`? We specified a clear criteria. >> > > You're dodging my question: isn't it better for the chaining to be > supported by the language semantics rather than be injected to APIs in > order to have support? > > >> After all, the APIs can't guarantee a `this` return, >>> >> >> Yes they can, they return what the specification defines them to return. >> > > 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. > > since they might have something actually meaningful to return, otherwise >>> we might as well just replace `undefined` with `this` as the default return >>> value. >>> >> >> In the cases I presented, I believe that returning `this` IS the >> meaningful return. >> > > No, it's a generic return value if it's applied to everything that's not a > getter. > > >> >>> We could introduce mutable primitives so that meaningful return values >>> could be stored in arguments, kinda like in C, but instead of error values, >>> we'd be returning `this`, heheheh. :) >>> >>> I'm curious, do you have any code examples of maps/sets that could be >>> made clearer by chaining? >>> >> >> This is incredibly frustrating and indicates to me that you're not >> actually reading this thread, but still find it acceptable to contribute to >> the discussion. >> >> https://gist.github.com/4219024 >> > > I'm sorry you feel that way, but calm down. I've read the gist all right > and just read the latest version, and imho it's quite a biased example, > you're making it seem harder than it actually is. For example, the last > paragraph: > > ( map.set(key, value), set ).keys(); > > // simpler: > map.set(key, value); > map.keys(); > > ( set.add(value), set ).values(); > > // simpler: > set.add(value); > set.values; > > ( set.add(value), set ).forEach( val => .... ); > > // simpler: > set.add(value); > set.forEach( val => .... ); > > Why would you need to stuff everything in one line? 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? > > Cheers, > Jussi >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
