While this a fairly good and useful statement, I would reword it just
a little bit to qualify that #eql? doesn't *have* to be synonymous
with #==. It usually is, and unless you're doing something far from
the norm it will be, but to call it "syntactic sugar" is not quite
accurate. I'd try a rewording like:
"#eql? is used in hash key collision resolution. Under nearly all
circumstances, #eql? will be synonymous with #==, and if your class
needs to override #== it will be sufficient to alias #eql? to #==.
Just note there are rare exceptions."
Jacob Fugal
···
On 6/27/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
#eql? is just syntactic sugar of #==, needed for objects used as keys
in hashes (because hash implementation doesn't like to use #==, but
only #eql?). If your class needs to override #==, than just delegate #eql? implementation to #==.
Sorry for this... pls blame me :-). I assume it is a feature, but till
I can figure it out how to use it for me it is just not-yet-a-feature
(no intention to sound harsh).
./alex
···
On 6/26/06, Robert Dober <robert.dober@gmail.com> wrote:
> >
>
> Thanks for confirming my point :-). I couldn't find a
Hey you will get me into trouble, I did *not* agree with your point, I
*accept* and *understand* it, my oppinion is not the only reasonable
seriously I think it is a feature, not the most important and maybe not the
least dangerous but a feature nontheless.
Cheers
Robert
good/workable/meaningfull example for having different implementation
> for == and eql?. I am still looking for.
>
> ./alex
> --
> .w( the_mindstorm )p.
> ---
> (http://themindstorms.blogspot.com)
>
--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.
Hmmm... for me it is not the name problem, but (hopefully nobody will
be agree because I keep repeating it) the fact that I really cannot
see a good example for having different implementations for == and
eql?. Once I see an example that makes sense, I will consider this
discussion closed (from my pov).
On Jun 26, 2006, at 10:20 AM, Robert Klemme wrote:
> 2006/6/26, Robert Dober <robert.dober@gmail.com>:
>
>> Personally I find this situation a bit odd. I'd prefer a single
>> > equivalence relation per class not two.
>>
>> Although I do not feel the same that seems a normal concern, as I
>> pointed
>> out to the OP.
>> Honestly I think it depends on the programming culture we are
>> coming from
>> and when
>> in our mind these are synonyms we are likely to get bitten by that
>> kind of
>> code.
>
> At the moment I'm not so sure whether culture is the background. I
> tend to think that there's a more fundamental issue: having a single
> equivalence relation defined on instances of a class seems to make
> things easier in several areas and I believe that it rather reduces
> programming errors.
Perhaps the issue is not so much having more than one, but having
unhelpful names for them. We don't get confused by the variety of
each-like methods available. And no one forgets the difference
between times, upto, and downto, despite their similarities. If we
had ==, same_place_in_memory, same_in_hash, and same_object_id (or
whatever they are) people wouldn't get confused even with lots of them.
Thanks Alex. This part of explanation is quite good. Continuing on the
same direction I have tried to create a Hash where for Fixnum 2 and
Float 2 to be able to have different values. And I couldn't figure out
any (except a somehow academic one: 2 => Fixnum, 2.0 => Float ).
./alex
···
On 6/27/06, Alex Young <alex@blackkettle.org> wrote:
Alexandru Popescu wrote:
> Rober, thanks and thanks. I think you are right. I am a little sad
> because I have hoped to find a good answer to this, so that others
> will have a good reference for this subject and will not have to pass
> through phylosophical times as I had when reading for the first time
> about equality in Ruby.
>
> Unfortunately, even if I play with Ruby for almost 2 years, I don't
> consider that I have enough knowledge to come up with authoritative
> posts, so this is the reason for my mildy posts. If this would have
> been on a Java subject, things would have been completely different
> ;-), but here I just try to keep myself "low profile" and extract as
> information as possible.
>
> Still, I have formulated a conclusion in the previous post, and that
> will be the one that will go to the entry for update:
>
> #eql? is just syntactic sugar of #==, needed for objects used as keys
> in hashes (because hash implementation doesn't like to use #==, but
> only #eql?). If your class needs to override #==, than just delegate
> #eql? implementation to #==.
Just to weigh in here on how I think of it, without this necessarily
being representative of any section of reality: #eql? is used for
value-and-type equality, where #== is used for value-equivalence. Thus
2.0 == 2 #=> true, 2.eql? 2.0 #=> false. For most types, they'll be
identical, because 98 classes out of 100 simply don't have a
value-equivalence relationship.
Of course, I could be very, very wrong about this, partially because the
only example I can think of off the top of my head where this is the
case is Fixnum == Float, and partially because it implies a certain
flexibility to the strongly-typed approach which seems quite
uncharacteristic.
Still, I have formulated a conclusion in the previous post, and that
> will be the one that will go to the entry for update:
>
> #eql? is just syntactic sugar of #==, needed for objects used as keys
> in hashes (because hash implementation doesn't like to use #==, but
> only #eql?). If your class needs to override #==, than just delegate
> #eql? implementation to #==.
Please be aware that this is in contradiction to the official documentation.
Can you please state how exactly this contradicts the official
documentation? I know you stated that before but somehow I miss your
answer to my question in an earlier post.
I don't think there is a contradiction, delegating eql? to == is a
valid way to achieve that both are implemented the same - with the
added benefit that this is maintained for subclasses also as long as
they do not decide to override eql?.
Maybe the doc is wrong but nobody has claimed that so far.
It will also break Hash lookup unless the reimplementation of #== is very
careful!
What do you mean by "careful"? Of course, =='s implementation should
be reasonable but careful? What additional caveats do you see?
( I will try to demonstrate this as soon as I have a little time )
I'm looking forward to that.
Hopefully everybody is backing me up on this one even if they think that is
how it *should* be. Right now it is *not* how it is.
I'm not sure whether we read the same documentation - I get the
feeling that we interpret the same text in different ways.
Kind regards
robert
···
2006/6/27, Robert Dober <robert.dober@gmail.com>:
On 6/27/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
The one question I do have regarding this is why isn't the default
implementation of Object#eql? as an alias to Object#==? The
documentation makes it clear that that's the intended behavior, and
the common behavior for descendants of Object as well. It seems odd
that it's not then codified as an alias. It seems redundant that we
have to always remember to alias #eql? if we override #==; why can't
it be the default to already be an alias?
Jacob Fugal
···
On 6/27/06, Jacob Fugal <lukfugl@gmail.com> wrote:
#eql? is used in hash key collision resolution. Under nearly all
circumstances, #eql? will be synonymous with #==, and if your class
needs to override #== it will be sufficient to alias #eql? to #==.
Just note there are rare exceptions.
Equality—At the Object <http://www.ruby-doc.org/core/classes/Object.html>level,
== returns true only if *obj* and *other* are the same object. Typically,
this method is overridden in descendent classes to provide class-specific
meaning.
Unlike ==, the equal? method should never be overridden by subclasses: it is
used to determine object identity (that is, a.equal?(b) iff a is the same
object as b).
but alias take a copy of the aliased method - so you'd still need to re-alias
right?
-a
···
On Wed, 28 Jun 2006, Jacob Fugal wrote:
On 6/27/06, Jacob Fugal <lukfugl@gmail.com> wrote:
#eql? is used in hash key collision resolution. Under nearly all
circumstances, #eql? will be synonymous with #==, and if your class
needs to override #== it will be sufficient to alias #eql? to #==.
Just note there are rare exceptions.
The one question I do have regarding this is why isn't the default
implementation of Object#eql? as an alias to Object#==? The
documentation makes it clear that that's the intended behavior, and
the common behavior for descendants of Object as well. It seems odd
that it's not then codified as an alias. It seems redundant that we
have to always remember to alias #eql? if we override #==; why can't
it be the default to already be an alias?
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
The one question I do have regarding this is why isn't the default
implementation of Object#eql? as an alias to Object#==? The
documentation makes it clear that that's the intended behavior, and
the common behavior for descendants of Object as well. It seems odd
that it's not then codified as an alias. It seems redundant that we
have to always remember to alias #eql? if we override #==; why can't
it be the default to already be an alias?
becuase this will change nothing
moulon% cat b.rb
#!/usr/bin/ruby
module Kernel
def x
puts "x"
end
alias xx x
end
Note something that's peripherally related to == and eql? is the
method "hash", which subclasses MUST override if they override eql? or
== so that the guarantee:
a.eql?(b) implies a.hash == b.hash
is maintained. If you don't do this, your new objects will do all
sorts of weird things when you try to use them as keys in a Hash or
elements in a Set.
Ah, good point. And after reading that, it got me thinking about how
the same question could be asked about why the default implementation
isn't something like:
class Object
def eql?(other)
self == other
end
end
And thinking about that, I realized why. As Daniel Martin mentioned,
the implication:
a.eql?(b) implies a.hash == b.hash
Should always be maintained. Now, if I recall correctly, the default
Object behavior is:
* hash returns the object_id
* equal? compares object_ids (this should never be overridden)
* == is implemented in terms of equal?
* eql? also compares object_ids (maybe also implemented in terms of eql?)
So by default, == and eql? are synonymous. But if we override ==, and
eql? were to implicitly follow, but we didn't also override hash, the
above implication would no longer hold. Chaos ensues.
So the primary reason eql? is separate from == is that eql? needs to
be sure to follow hash. So now my question is: why isn't the default
implementation of eql? to compare hash instead of object_id? Then we
can override hash in cases where we want to, and not need to worry
about eql? unless we really need to...
Jacob Fugal
···
On 6/27/06, ts <decoux@moulon.inra.fr> wrote:
> The one question I do have regarding this is why isn't the default
> implementation of Object#eql? as an alias to Object#==? The
> documentation makes it clear that that's the intended behavior, and
> the common behavior for descendants of Object as well. It seems odd
> that it's not then codified as an alias. It seems redundant that we
> have to always remember to alias #eql? if we override #==; why can't
> it be the default to already be an alias?
).
into this post: