Hacker News Reader

Comment by neilk | Hacker News Reader

Skillful practictioners of OOP, even in languages like Java, know this stuff already. It's just that the language leads newbies astray by making inheritance such a prominent concept.

To a first approximation, inheritance is always wrong. The Design Patterns book advocates composition -- building up an object out of smaller ones -- over inheritance. Yeah there's more work to delegate messages around, but if you didn't like typing you shouldn't have picked Java (or, use an editor that makes this easier).

Also, when trapped in languages like Java, define behaviour in terms of interfaces rather than inheritance. Interfaces are exactly what raganwald is talking about -- they define the ability of something to respond to methods, but are decoupled from any parent-child relations.

View on HN

Dynamic languages like JS, Ruby and Python could greatly benefit from explicit support for interfaces as well. I'm enjoying the fact that Clojure brings this powerful abstraction to a dynamically typed language.

Python has interfaces. There isn't even a need for it to be supported by the language. I don't see why Ruby or JS couldn't support them as well.

http://pypi.python.org/pypi/zope.interface http://docs.python.org/library/abc.html

Can you give an example of where one would want to use an interface or an abstract base class in a dynamic duck-typed language?

I looked quickly at pep-3119 and it seems like it's a short-hand way of checking if an object will respond to some set of methods.

Now, I cop to having done type checking in Ruby (either with is_a? or respond_to?) but I always felt it was a code smell, a hack to solve a distraction while I moved on to something else more pressing.

I don't know a whole lot of Python, but I'm guessing that since Python has a more Java-like form of OOP (i.e., method invocation vs. the message passing of Ruby, a la Smalltalk) this kind of type-checking is quite acceptable, even though Python is ostensibly duck-typed.

Am I wrong, and by how much?

About the only thing I use is_a? for routinely in Ruby code is to allow a particular function to accept many types of things as arguments. (An array? Sure! A single object? Why not? A single ActiveRecord id? Don't sweat it, I can do .find(id), too!)

You could even do away with is_a? there and just ask if the argument responds_to a particular method and then call the method if it does. I find myself doing more of this and less of calls to is_a? these days.

It's conceptually much cleaner, too. If you're asking about the type of something, you're almost always just trying to see if it has some method. Just ask about the method response directly.

Ostensibly, Python has a more Java-like model of method invocation, but this is really only a semantic difference. There is little that you can do with Python methods that you can't do with Ruby's methods and vice-versa.

Generally, checking the type with isinstance is considered bad practice although it can be useful sometimes (I can't think of any simple examples off the top of my head though).

The main reason I can think of for using an interface or abc is simply so that if you forget to add a required method, the exception gets thrown sooner rather than later. Plus with an abc, you also allow the base class to define methods that depend upon abstract methods (for instance, if you subclass the Mapping abc, you get __contains__, keys, items, etc for adding __getitem__). Strictly speaking, there's no reason why you can't do that without an abstract base class, but it makes it easier.

In short, there are useful reasons to have interfaces and abstract base classes in Python, but they probably aren't the same reasons you'd want them in a statically-typed language like Java.

Twisted, the Python networking framework, makes extensive use of interfaces in its API. The "Interfaces and Adapters" chapter in the documentation goes in to some detail about why you would want such a thing:

http://twistedmatrix.com/documents/current/core/howto/compon...

If you're in a hurry, the main motivations appear to be:

- declaring that a class supports particular functionality without risking the complications of multiple inheritance - the ability to register adapters from one interface to another means no more calls to isinstance() (or at least, they're abstracted away to a library function) - Easy to make your test suite check that you haven't forgotten to implement any methods of any of the interfaces your class claims to support.

"I want to say one word to you. Just one word." -- Plugins ;-)

You can pick out a set of objects that implement a certain interface from a larger set. You can do this for classes, objects, perhaps modules.

Someone already mentioned Twisted plugins. They currently use Zope interfaces. You create a class then declare that it implements a particular interfaces.

There's a difference between having a language feature (or it's possibility) and actively encouraging it. Far too many classes are bag of a implementation details with no thought for a design. In Clojure you can't just declare methods willy-nilly. You must implement methods that are a part of protocol (interface). This encourages two things, a) interoperability and b) the creation of new reusable designs- implementations rightfully take the backseat.

Haskell type classes seem, to me, to take the right approach here as well. In fact I would argue their main benefit is not catching programmer error - but encouraging thoughtful design.

By this logic every language should have C-style headers. There's nothing to prevent me from creating a bloated API/interface with or without the framework forcing me to declare it external to the class, in interfaces, headers or otherwise.

In Eclipse it's as simple as using the refactor tool to 'pull up interface' from any God Class of my choosing.

Neither language nor framework can force a coder to apply the Single Responsibility Principle. Coders can be willy-nilly with or without interfaces.

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

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).

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. :-)

This might make sense for Clojure (I haven't used it) but in my years of Ruby programming (after 10 years in Java and C#) I have never thought to myself, man I'd love to have an interface here. Ruby's lack of class-level contracts is essential to its idiomatic nature, a strength not a weakness, imo.

Generally speaking I like interfaces, but Ruby is so dynamic that you couldn't use them for compile-time guarantees. Interfaces could only get you a slightly nicer way of dynamic duck typing. I wouldn't really call all of the dynamism a strength though - one of the limiting factors of compile time evaluation here is that a method can later become undefined- when is the last time you needed that?

Actually, undefining methods on an object because such an idiom that Ruby 1.9 introduced a new base class into the hierarchy: BasicObject. [1] This is now the new root class, above Object.

1: http://www.ruby-doc.org/core-1.9/classes/BasicObject.html

Yeah, that is the 1 case, and ActiveSupport has had a BasicObject for a while now. This is another case where proponents would say it is great that you can undefine a method, but I would say that is a hack for lack of any namespace management. Now that there is a BasicObject I am not sure that there is any practical use for undefining a method- probably only for dealing with namespace collisions, which again seems to point out a language flaw, not a feature of dynamism.

This is short-sighted. The key point in your statement is "I". Contracts are not about "I". They are about everyone else. You have a great design and interfaces allow you to share that.

This simply makes no sense in a Ruby idiom (and I'm not really sure this is the best way to think of it in Java either -- I can make an API public and well-documented with or without interfaces.)

I've used dozens of Ruby gems, plugins and classes over the years that have well-documented shared APIs and none of them (obviously) have had interfaces. Interfaces are good in certain environments for hiding implementation details where class-level contracts are enforced, but in Ruby this would provide no benefit at all.

Think of it this way: since Ruby has no class-level contracts, to some extent everything is already an interface. Everything is abstract. Every Ruby object has the opportunity to re-implement functionality in an abstract way.

Seems to me that Ruby modules affect the same outcome as an interface without all the overhead. Just include the module & you've got the desired behaviors and data types without all the fuss.

You get exactly the same benefits as you would from an interface (minus the rigidity)...

I've been working in C#/.NET for a while and I've started using Ruby recently for a couple of different projects at home. It's messing with my head because I'm starting to kind of hate the rigidity I'm forced to work with when I'm deciding whether I should/should not implement an interface.

That said, yes, Ruby with interfaces seems kind of pointless and is just throwing more code in, which is the opposite of one of the nicer points of the language.

Missing the point entirely. I don't want your module. I want/like your design and I want to provide my own implementation.

Override the functions in my module with your own

Define exception throwing "not implemented" methods in the module.

I get what you're saying, but Ruby already allows you to do this. If you like an API/design, then go ahead and reimplement it however you like. There are no class-level contracts anywhere in Ruby that would prevent this, and therefore interfaces provide no additional level of abstraction that Ruby doesn't already have.

Although you could probably use any OOP capable language with GoF, I think the D language fits really nicely for that book. D defines interfaces, abstract classes, subtyping, (class) mixins, templates, all in the language, and has a safe override mechanism for when inheritance is the preferred approach in an OOP pattern.

This is one of the reasons why I love Go, the language is designed to make both composition (with 'embedding') and interfaces (with 'static-ducktyping') very convenient and easy, while completely avoiding the inheritance minefield.

Reply on news.ycombinator.com