“The evolution problem of Java interfaces still applies. If you ever only need one method on which Payroll depends, then your Java interface also only needs on method. If the interface needs more methods, most probalby because of the Payroll, then evidently you depend on more than one and all the workers need to change also.”

Some more thoughts:

“Structural typing also introduces couplings of its own: suppose both A and B have close() and you rename the one in A: you now have to rename close() in B as well.”

With interfaces and structural typing you cannot change method names in the dependent class, or it won’t compile (or you would need as you’ve said, change all names). So this it not “coupling of it’s own” I think.

Three packages A,B,C
A contains the interface
B contains the class
C uses the interface

B -> A
C -> A,B

A contains the class
B uses structural typing

B -> A

“It also introduces indeterminism in automatic renamings for similar reasons.”

This surely is a problem, I often blogged about dynamic languages (e.g. Ruby). You need a runtime sniffer to detect such dependencies for safer refactoring.

Structural typing borders on “respond_to?” in Ruby (but with the benefit of compile time checking) and – if you do not think about what you do – will lead to brittle classes.

Structural typing couples you to a method name while the others couple you to a class, not sure it’s such a huge gain.

Structural typing also introduces couplings of its own: suppose both A and B have close() and you rename the one in A: you now have to rename close() in B as well.

It also introduces indeterminism in automatic renamings for similar reasons.

The API book was really an eye opener for me, I still love interfaces, but I’m aware of their dangers.

But thanks for commenting, I value your opinion very highly.

Basically, I think the only reasonable options here are interfaces, abstract classes and traits.

Structural types have are beaten by each of these three options on different criteria and I don’t really think they have their place in code that is longer than ten lines.

I still disagree with you

- DRY: Use a type alias
- Semantic problems also exist with interfaces

As a developer one needs to decide when to use interfaces, abstract classes, traits, structural typing.

After reading the excellent “Practical API Design: Confessions of a Java Framework Architect” I realized 90% of Java developers don’t know what they do when they design an API and decide between interfaces and abstract classes.

[1] The second comment was from me

Here is why:

http://beust.com/weblog/2008/02/11/structural-typing-vs-duck-typing/

http://gist.github.com/293666

def using[A < : {def close(): Unit}, B]
  (param: A)(f: A => B): B = 

  try {
    f(param)
  } finally {
    param.close()
  }

Now you can safely use any object with a close() method and be assured it will be closed when you’re done. A lot of Java classes implement the java.io.Closeable interface, but many do not (JDBC’s Connection, Statement and ResultSet are a few).

val conn: Connection = …
using (conn) { conn => //do stuff with conn and it’ll get closed }

using (new BufferedReader(new FileReader(“file”)) { reader => //do stuff with reader and it’ll get closed }

using (new PrintWriter(new FileWriter(“file”)) { writer => //do stuff with writer and it’ll get closed }

Structural types used to not be thread-safe: https://lampsvn.epfl.ch/trac/scala/ticket/1006, but apparently this has been fixed. Not sure if it’s fixed in 2.7 or just 2.8?

(Stephan: Fixed displayed code)