>From my perspective, I never use arrays to store objects of different types
(I think that sort of thing belongs in an object of its own). So in theory I
don't particularly care either way. However, == seems to be the standard way
since many methods use include, which uses ==, or use == directly. I think
=== is particularly useful when you are trying to restrict an operation to a
type in addition to the value and I don't see array or enumerable operations
as needing that restriction. In addition, AFAIK, the only values that could
be matched between types are numbers, strings, and booleans, which I don't
see as very harmful.
Allen Madsen
http://www.allenmadsen.com
On Thu, Sep 3, 2009 at 6:20 PM, kangax <kan...@gmail.com> wrote:
>
> On Sep 3, 1:55 pm, Allen <bla...@gmail.com> wrote:
> > Hi all,
> >
> > I was looking into some of the array methods and noticed this
> > inconsistency.>>> [1].without("1");
> > []
> > >>> [1].intersect(["1"]);
> >
> > []
> >
> > Basically, without uses an == comparison, whereas intersect uses an
> > === comparison. IMHO, I think == is more appropriate. As such, I have
> > forked the prototype repo and modified intersect. You can view the
> > diff here:
> >
> > http://github.com/blatyo/prototype/commit/8b9a7b721ef787110f85c03a28c...
> >
> > I also created a test to see how the two methods performed against
> > each other. See that here:
> >
> > http://groups-beta.google.com/group/prototype-core/web/uniontest.tar.gz
> >
> > Here are some of the results I got in milliseconds (running on
> > chromium):
> > Testing New Intersect
> > 4517
> > 4614
> > 4823
> > 4998
> > 4856
> >
> > Testing Old Intersect
> > 7321
> > 7337
> > 7376
> > 7353
> > 7331
> >
> > Let me know what you guys think.
>
> There's also `uniq`, which relies on `==`:
>
> [1, 2, 3, '1'].uniq(); [1, 2, 3]
>
> `without` actually relies on `include`, so it is `include` that would
> need to be changed. I think I'd rather see `===` used instead of `==`
> where possible, although there are probably cases when `==` is more
> convenient.
>
> Btw, `NaN` inequality to each other might be confusing in context of
> `uniq`. It might be worth mentioning in the docs that `[NaN, NaN].uniq
> ()` results in the very same `[NaN, NaN]`.
>
> --
> kangax
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---
