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
On Tue, Sep 8, 2009 at 7:33 AM, Tobie Langel wrote:
>
> > Tobie,
> > Do you have any input on this?
>
> Yes, I'm in favor
> Tobie,
> Do you have any input on this?
Yes, I'm in favor of strict equality.
--~--~-~--~~~---~--~~
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@googlegroup
Tobie,
Do you have any input on this?
Allen Madsen
http://www.allenmadsen.com
On Mon, Sep 7, 2009 at 8:00 AM, Joran wrote:
>
> 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.inclu
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
--~--~-~--~~
>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
On Sep 3, 1:55 pm, Allen 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 m
