Pure win: Array.from and Array.of

Andrea Giammarchi andrea.giammarchi at gmail.com
Sat Jul 30 07:24:30 PDT 2011


Alex I think whatever method we have natively won't be enough for this or
that case, plus once a method is implemented native his signature becomes
legacy developers may like or not.

With Object.defineProperty we *could* pollute Array.prototype avoiding the
most annoying and idiotic thing developers have been historically complained
about ( and "I really don't know why" ): the for/in loop

Same is for Object.prototype so ... we already have the power to add the
sugar we may or may not need ( I am *not* saying anybody should do this
) but what is missing is some kick ass performances method and not the whole
Prototype/Dojo framework in core, imo.

In few words, it won't surprise me if at some point some library/framework
will go out with such code:

Object.defineProperty(Array.prototype, "remove", {
    enumerable: false,
    writable: false,
    configurable: false,
    value: function (value, all) {
        var i = 0;
        do {
            i = this.indexOf(value, i);
            if (-1 < i) {
                this.splice(i, 1);
                all = all && true;
            } else {
                all = false;
            }
        } while(all);
    }
});

Then we gonna have problems with live collections, the fact is missing the
index to start with the removing operation or who knows what other
edge/adhoc case ... and this is just for an extra remove so, why bother with
all possible frameworks sugar?

It makes sense if we have real usages in numbers rather than the fact that
"if it's there it surely means developers need it", don't you agree?

Don't get me wrong, the more we have the more powerful/fast the language
looks like but I am not sure we really need all these shortcuts.

Andrea

P.S. about non Array specific stuff, I am looking at typed Array *big time*
... there I would never complain about a Vec3Array with a multiply(Vec3)
native method for sure!


On Tue, Jul 26, 2011 at 7:59 PM, Alex Russell <alex at dojotoolkit.org> wrote:

> 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 <
> 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.
> >>
> >> Allen
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
> --
> Alex Russell
> slightlyoff at google.com
> slightlyoff at chromium.org
> alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110730/63961b23/attachment.html>


More information about the es-discuss mailing list