Array#intersect and Array#without inconsistency

[Allen]

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/8b9a7b721ef787110f85c03a28c3cdb3c67dbe34

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.

[kangax]

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

[Allen Madsen]

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

[Joran]

Re: Array.uniq and Array.include and '==':

There's a bug in the existing Array.uniq where [false, 0].uniq()
returns [false]. I would prefer '===' for Array.include.

See: http://prototype.lighthouseapp.com/projects/8886/tickets/786-optimize-arrayuniq-to-return-in-on-time

[Allen Madsen]

Tobie,

Do you have any input on this?

Allen Madsen
http://www.allenmadsen.com

[Tobie Langel]

> Tobie,
> Do you have any input on this?

Yes, I'm in favor of strict equality.

[Allen Madsen]

There seems to be more support for strict equality, so I'll write up a patch with that and modify some test cases around the change.

Allen Madsen
http://www.allenmadsen.com