More Enum.equal? stuff

[meh]

Added a specialization for Range, because it could do a lot of useless work when comparing two ranges.

Also added Enum.equal?/3 with an additional function to check for equality, useful in many situation, and also to easily compare with === instead of ==.

[josevalim]

The protocol (or a protocol wrapper, which is the case for Enum) should not
reference implementions directly. Doing this partially defeats the goal of
protocols since we are giving preference to our own data structures, since
user made ones wouldn't achieve the same result.

There are many cases we could fit in here, for example, any ordered set or
ordered dict implementation could be specialized too. I think the best we
can do for now is document it. If we want to provide fast checks, we should
allow the protocol to optionally implement a function like .fast_equals?
and check if it exists with function_exported?. Unfortunately, today there
isn't an easy way to check if a protocol exports something, this will be
available after the protocol consolidation thing is implemented (there is
an issue for it but I am on my phone :P)

José Valim
www.plataformatec.com.br
Skype: jv.ptec
Founder and Lead Developer

[yrashk]

I don't buy this argument. Having all cases slow is worse than having
known cases faster and the rest slower. Besides, we already have list
specialization in Enum.

[josevalim]

The list specialization is available to all types. A set could use it.

I am not saying we shouldn't specialize, all I am saying is the
specialization mechanism needs to be available to all types.

José Valim
www.plataformatec.com.br
Founder and Lead Developer
*

[yrashk]

Range is quite built-in, though.
On Apr 27, 2013 11:10 AM, "José Valim" notifications@github.com wrote:

The list specialization is available to all types. A set could use it.

I am not saying we shouldn't specialize, all I am saying is the
specialization mechanism needs to be available to all types.

José Valim
www.plataformatec.com.br
Founder and Lead Developer
*

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/983#issuecomment-17120566
.

[meh]

So add equal? to Enum.Iterator?

I was somewhat against the specialization for just ranges, but @shurizzle insisted I should do it, and in the end I considered ranges built-in given there are translations in elixir_macros.ex just for them, so I added it in.

Nonetheless, considering adding equal? to Enum.Iterator doesn't sound like a bad idea given we are adding it to Dict too.

I can remove that commit for now and think about it later tho.

[yrashk]

I would still say specializing for Range sounds quite reasonable to me (it really is quite built-in)

[meh]

Any news on this? I'd at least like to have Enum.equal?/3 merged in.

[josevalim]

In the end I considered ranges built-in given there are translations in elixir_macros.ex just for them, so I added it in.

We should remove that and make it general, it is just low priority.

Nonetheless, considering adding equal? to Enum.Iterator doesn't sound like a bad idea given we are adding it to Dict too.

I think this would be the way to go. If both iterators are equal, dispatch to the protocol. The problem is that we can't know if they are equal without #950. So I am closing this for now until we get #950 in. Thanks @meh !

[josevalim]

Ugh, my bad. Reopening this as I missed Enum.equal?/3. @meh could you please remove the Range bits?