Pure win: Array.from and Array.of
alex at dojotoolkit.org
Tue Jul 26 10:59:45 PDT 2011
On Jul 26, 2011, at 7:10 AM, Andrea Giammarchi wrote:
> glad somebody said that!
> Also I would pollute performance oriented methods rather than "whatever
> framework sugar" anybody could easily add where unique() and remove(all) may
> be part of these cases while fill() could be superfluous.
I feel like i have to stick up for "framework sugar". This stuff is getting sent around the network at dizzying expense in latency, bytes, and collision potential/workarounds. Framework sugar is only dismissible in a world where you can *actually* extend the prototypes, and that means being in control of the entire app today. Few (if any) frameworks can do this right now, and without something like SOE, it's not clear to me that the dynamics are set to change. That leaves us in a place where it's up to the language to add the sugar we all would like to see, else nobody (credibly) can. So lets either stop calling it "sugar" when libraries do it or start acknowledging that sugar isn't a cheap import.
> On Mon, Jul 11, 2011 at 6:01 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
>> On Jul 10, 2011, at 12:09 PM, Dmitry A. Soshnikov wrote:
>>> And by the way, an efficient `Array.prototype.unique` also would be nice
>> to have, since in JS in general it's hard to implement it's efficiently (in
>> lower level at least it will iterate faster).
>>> [1, 3, 2, 5, 5, 3].unique(); // [1, 3, 2, 5]
>> Before considering adding too many things to Array.prototype we perhaps
>> should start considering the protocol of a real collection hierarchy that
>> goes beyond just arrays.
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
slightlyoff at google.com
slightlyoff at chromium.org
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
More information about the es-discuss