http://www.texperts.com/2007/10/16/navigating-the-equality-maze/

• equal?: object identity
• ==: objects have the same meaning
• eql?: objects represent the same value

So if you consider numbers:

1 == 1.0
=> true
1.eql? 1.0
=> false

This means that you can have a hash with a keys of both 1 and 1.0 (which wouldn’t be true if hash used ==):

h = {}
h[1] = 'an integer'
h[1.0] = 'a float'
h
=> {1=>"an integer", 1.0=>"a float"}

Regarding ===, this exists to enable some of the nice syntactic sugar that Ruby’s case statement supports. For example:

(1..10) == 4
=> false
(1..10) === 4
=> true

Which means that you can write this kind of thing:

kind = case lines
  when 1..10: "Short"
  when 11..25: "Medium"
  when 26..50: "Long"
  else "Too long!"
end

Regular expressions can play the same kind of trick:

kind = case moment
  when /\d\d:\d\d:\d\d/: 'time'
  when /\d\d\/\d\d\/\d\d/: 'date'
  else 'other'
end

As can classes

case thing
  when String: # Handle strings here
  when Numeric: # Handle numbers here
  # etc...
end

Java doesn’t have special equality of switches or entry into hash tables… I don’t really see why one would want to make these different.

The spaceship operator doesn’t have an equivalent operator in Java, but it seems the same as the Comparable interface.

Regex matching in Java is through the Pattern and Matcher classes. It’s a bit more formal than the Ruby equivalents… the String.matches() method is a convenience for simple regexes. I’d also like to see more attention given to indexing of Strings for repeated searching, but nobody seems to have picked up on my post.

Ruby is a very interesting language… the book I bought concentrated on comparing Rails to the insane J2EE frameworks out there. There were parts were I believe Java won hands down (Hibernate for persistence), and others where Ruby destroys Java (e.g. templating)… but as for the language itself, I was comparing it more with Python than Java. As a prototyping language, I’d probably go with Python, but I’m still interested enough in Ruby to continue learning it. The lack of IDE support is a pain, but that’s probably because Eclipse has spoilt me these last few years.

Things Java could learn from Ruby are:-

• limited subset of operator overriding (even C++ has this… come on Java!)
• shorthand notation for getter/setter variables
• the int/Integer/BigInteger thing is a real pain in the butt. It would be amazing if this were transparently built into the language like in Ruby. The Haskell solution is even better… Int is basically {int, Integer} and Integer is BigInteger. However, that would break so much backwards compatibility it’d have to be a new language; It has performance consequences and would break almost all native code out there.

Things are also different in Ruby because the philosophy underlying the type system (duck typing) is altogther from that underlying Java’s. So I’m not even sure that the same philosophical issue as the one you’re worrying about really exists in Ruby.

Ruby provides two “core” equality operators. Object#equals? and Object#==. Both of these can be overridden, and both by default just check for object identity.

The difference is that the intention is that you shouldn’t override equals? (i.e. it should remain object identity), whereas the expectation is that == should implement “natural” equality, whatever that means in context. Most of Ruby’s standard classes do override == (so, for example, Array#== returns true if both arrays contain the same number of elements and if each element is equal according to their own implementation of ==).

So, basically, it’s down to you to provide value semantics. The language doesn’t try to do it for you. If you build your app mainly from standard classes, though, mostly it “just works” because they have done most of the work for you.

It’s complicated (or simplified, depending on how you look at it) by the fact that Ruby provides other comparison operators over and above equals? and ==, specifically:

=== (case equality) which is used within case statements

eql? which is used when inserting objects into hashes (so, overriding eql? implies that you should also override hash)

<=> (the “spaceship” operator) which implements comparison for objects which support ordering.

=~ which implements regular expression matching.

Your question has prompted me to do a bit of searching to see if I can find a good discussion of the various different comparison operators in Ruby, and there doesn’t really seem to be anything out there (although there is quite a bit of misinformation!). I may see if I can knock something together for our blog

How does ruby handle equality (not identity) between objects? And more importantly, how does it handle the pitfall case of class compared against subclass?

I think I’ll try making those tidying edits to the move method, but I don’t think the Java solution for this problem is going to look as elegant (or anywhere near as terse!) as the ruby one The main reason being the lack of operator overriding for collections. I really really wish they’d add it one day! I can’t see it happening.

PS: I’ve added that extra Java code… I didn’t remove it though, it just wasn’t there. This whole code highlighting thing is a bit of a hack to get working with Markdown, so sometimes it just completely falls over. I’ve installed alternatives but they don’t deal with generics very well.

Check this:

http://wordpress.org/extend/plugins/ajax-comment-preview/

I’m familiar with the argument that because code is automatically generated it doesn’t matter that it’s verbose. I don’t buy it though. It might save you time when you’re writing it in the first place, but it still dramatically affects the maintainability of the codebase. Partly because it increases the amount of “clutter” you have to pick your way through, but mainly because it leads to huge quantities of “almost” duplicated code.

Almost duplicated code is the worst kind. Purely duplicated code is bad, but almot duplicated code is really dangerous. You either have to pick your way through it every time you read it to make sure that it really is doing what you think it is, or (more likely) you skip over it thinking “ah yes - that’s the standard automatically generated boilerplate”. Which is fine right up until someone has (intentionally or accidentally) modified it. At which point your mental model is broken. And its broken in a way which is particularly difficult to spot because the pattern matching that the human brain is particularly good at suckers you into it.

It strikes me that there are two ways in which you can cope with complexity. You can automate the process of generating it or you can remove it. That’s the difference between a code generating wizard and something like Rails. I know which of the two I prefer…