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.
Regards
On Mon, Jul 11, 2011 at 6:01 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
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.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Alex Russell
slightly...@google.com
slightly...@chromium.org
a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
