On Tue, Dec 4, 2012 at 3:07 PM, Andrea Giammarchi < [email protected]> wrote:
> it would be nice to add a #put(key, value) that returns value and see what > developers prefer on daily basis tasks :-) > > anyway, if it won't change, it's OK, I had my answer, thanks > I like surveying actual developer-users like this, despite the committee's aversion to "design-by-survey". I sent out a survey 2 weeks ago and received 381 responses, 256 for return-this and 125 for return something else (undefined, the new length or size, the value). If the results had been different, I would've removed the item from the agenda entirely, but they are as I expected them to be and I feel compelled to take that into consideration. This survey was not mentioned as a part of my proposal and therefore had no influence on the decision made by the committee. Rick > > On Tue, Dec 4, 2012 at 12:03 PM, Rick Waldron <[email protected]>wrote: > >> >> >> >> On Tue, Dec 4, 2012 at 2:46 PM, Andrea Giammarchi < >> [email protected]> wrote: >> >>> 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. >>> >> >> That is exactly what I described—the case for returning a fresh jQuery >> object exists to support end() (http://api.jquery.com/end/) which allows >> you to chain operations (eg. filter->apply css or something) and restore >> the original jQuery object (matching set of elements) by keeping a >> reference to that object stored as a property of the new jQuery object. >> This mechanism is irrelevant in the comparison of Set API semantics. >> >> Rick >> >> >> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
