Re: ruby abstraction

On Saturday, July 17, 2010 08:21:10 pm James O'Brien wrote:
> I have found the concept of an interface invaluable in my Java programming
> and wondered if there were an equivalent concept in Ruby?

Yes and no.

Yes, there is certainly a concept of an "interface" -- this is an abstract 
concept that really applies to all languages. But no, it's not built-in to the 
language.

More specifically, the Java concept of an interface is only really needed 
because Java is statically typed.

> as a thought-experiment I
> propose Java without interfaces would be worse

Probably.

Take some common examples from the Java standard library -- Map would be a 
good one. Now, Interfaces are especially cool because I don't have to care 
that an object actually uses a hash internally -- it might use btrees, it 
might use something entirely different -- all I care about is that it claims 
to behave roughly like a Map is supposed to, and it presents get(), put(), and 
so on.

So, for example, I could declare an object to have a type like this:

Map<String, List<String>> files;

You could conceivably store these files as a HashMap, mapping filenames to 
lists of lines in the file. Of course, the cool part about interfaces is that 
it could also be a thin wrapper around a real filesystem (so you don't have to 
slurp them all at once), or it could talk to a database, or any number of 
things.

But on closer examination, was that actually the right abstraction? What are 
you doing with those files that you care that they're lists of strings, and 
not one giant string or an IO stream of some sort?

In the statically-typed world of Java, it makes sense that you would define 
your interfaces up front like this, because everything needs to have a type, 
and types are all defined and planned out ahead of time. It's not just that 
it'd be horrible design to do this:

Object files;

It's that it wouldn't work -- in order to call any methods on it, you still 
need to typecast it to something you know how to interact with.

In Ruby, things are a bit different. We have this concept called "duck typing" 
-- if it quacks like a duck, it may as well be a duck, who cares what it 
actually is? If it isn't a duck, it should break our unit tests, which is I 
think where it ties in to your comments here:

> I'm well versed in
> the benefits of test driven code and documentation but we have this in Java
> too

Since Ruby is dynamically-typed (and duck-typed), I don't specify the 
interface I need -- at least, not directly. I specify it by how I actually use 
the object in question:

puts files['readme.txt']

Now, there's still an implicit interface -- in this case, "Something that 
responds to [], and returns something which puts knows how to turn into a 
string." But I don't have to spell that out in code -- again, either it works 
(which it does, 99% of the time) or it causes a runtime issue, which is what 
unit tests are for.

That's the crucial difference -- in Ruby, I can just blindly fire a method 
call on an object, without knowing what type it is. In Java, I can only call 
methods on the object when I know it's of a type that supports those methods, 
and which type it is.

So, in Java, interfaces actually let you do things you wouldn't otherwise be 
able to do. In Ruby, I don't really see what purpose interfaces would have, or 
what they would enable me to do. I much prefer the implicit duck-typing 
interfaces. If it's a situation where I need an explicit interface as 
documentation, I think documentation works well enough.