Hacker News Reader

Comment by SpikeGronim | Hacker News Reader

I'm curious why you want interfaces in languages with duck typing.

Aren't interfaces essentially a reification of duck typing? If it implements the duck interface, it's a duck. So the reason you'd want it is just to have a conventional way to define what a duck is, and ask if an object was one. (And you could probably implement this in about three lines of Ruby.)

Now, many languages with formal interfaces (e.g., Java) are strongly typed, and they treat interfaces as types. Thus, for example, classes have to declare up front what interfaces they implement. That doesn't fit well with the flexible attitude of a duck-typed language. However, if interfaces were just collections of method signatures that could be tested against objects at runtime, that would be perfectly compatible with duck typing.

Languages like Modula-3 that use structural type equivalence sort of do this even in a strongly-typed system. Sort of.

So in duck typing, a "duck interface" would just be a shortcut way of asking "is this thing I've got the kind of duck I want?" Is there a language like that? I would like that.

This presumes I ever want to ask an object what its type is, but that's generally not a good OO way to accomplish something. I'd rather tell the object what to do and assume it does the correct thing for its given type. If I must, I can always ask if it understands a given message, but that's to be avoided as well.

Interfaces are useful in defining what an implementor must provide, but an example implementation does this as well.

this.

Also, if it helps, just think of the impl as an interface with a default behaviour that should be overriden ;)

If this is too forgiving, then we can even have the impl methods throw errors ("override me!") and simulate an interface.

In Smalltalk, I can have all the methods throw

    someMethod
        self subclassResponsibility

and then use the realize class refactoring on a subclass to generate stubs for all methods I must implement, just like an interface.

I think the Ruby way wouldn't be ask the object if it's a duck, but rather to ask it responds to the fly method, or the swim method, or maybe even the quack method, etc. In other words, you don't really care if it's a duck, just if it can accept the message you're about to send it.

So you're checking if it implements an intersection of single-method ducktypes. Now if only there was a way to reify that intersection and give it a name...

... but this isn't done very often, and is generally considered a Bad Idea, so let's not encourage it with a special language construct.

What exactly is the bad idea here? Having more than one method in a duck-type?

is_a? and respond_to? are code smells.

Yes, I agree. I wasn't actually suggesting to sprinkle instanceof-checks throughout the code.

What I was trying to get to: if you accept the existence of single-method ducktypes (like "things that have a walk() method" oder "things that have a quack() method"), then by intersecting these concepts, you arrive at things just like interfaces, whether you call them interfaces or not. If you want the pond system to work with your two-legged bird-sound robot, you perform the same mental steps as when implementing an interface. Hence, ducktypes could be seen as interfaces without an instanceof-operation.

Not "the message you're about to send it", but "the set of messages you might send it". Duck typing is not limited to a single message.

For example, a hash-based collection might require that all its members implement an equality method and a hash method. Typically in Ruby you test this by just waiting for one of those method calls to blow up somewhere in the hash table code. Instead, you could test "acts_like?(Hashable)" -- meaning "reaponds_to?(:=) && responds_to?(:hash)" -- on insertion. Then you could give a nice, meaningful error message at a nice point in the code.

Note that this has nothing whatsoever to do with is_a?, which is the important difference between this and type-based interfaces as in Java.

Absolutely. That's exactly what I wanted to say, stated far better than I could. :-)

Because it allows programmers to define a minimum contract for behavior. Instead of having to subclass (and being implicated into a hierarchy) you can instead provide any object as long as it satisfies that interface.

Allowing a class-level contract would fundamentally alter the dynamic nature of a language like Ruby. It might be cool (although I personally don't see the benefit), but it wouldn't be Ruby.

What mechanism would enforce the contract anyway? The best you could hope for would be a runtime error thrown when the interpreter detected the incompatibility, and you can do that manually now (I do it frequently to imitate abstract classes).

  class IAnimal
    def growl
      raise
    end
  end

Yeah exactly! 'raise "not implemented"' is how I imitate abstract classes (on the rare occasion that I need them).

Reply on news.ycombinator.com