[Prototype-core] Re: Array#intersect and Array#without inconsistency

2009-09-08 Thread Tobie Langel

 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@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
-~--~~~~--~~--~--~---



[Prototype-core] Re: Array#intersect and Array#without inconsistency

2009-09-08 Thread 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


On Tue, Sep 8, 2009 at 7:33 AM, Tobie Langel tobie.lan...@gmail.com wrote:


  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@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
-~--~~~~--~~--~--~---



[Prototype-core] Re: Array#intersect and Array#without inconsistency

2009-09-07 Thread 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
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



[Prototype-core] Re: Array#intersect and Array#without inconsistency

2009-09-05 Thread 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


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
-~--~~~~--~~--~--~---



[Prototype-core] Re: Array#intersect and Array#without inconsistency

2009-09-03 Thread 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
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---