On Tue, Dec 4, 2012 at 1:55 PM, Andrea Giammarchi < [email protected]> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
