:Like clothes.launder() vs money.launder(), or shape.draw() vs blood.draw(),
:or matrix.norm() vs hi.norm() ? I’m afraid English thrives on puns,
:and the same word routinely means radically different things across
:application areas. Therefore, to insist that a word have “one true meaning”
:in a programming language is insisting that the language cater to one true
:application domain.

http://groups.google.com/group/comp.lang.python/browse_thread/thread/c12d4b19d0f42f05/3acb79797dd3d3fd

Most people are pretty good at guessing the semantic of words depending on the context used. Having to define the precise semantics of every word each time it gets used sounds pretty verbose to me. Of course this might potentially create some bug (and is source material for jokes by comedians). BTW, Java interfaces don’t even allow to implement methods of different domains with the same name for a class, so Java interfaces don’t even solve the problem. I wonder how Haskell handles that.

Yes, people might define perverse methods which have the same names as normal ones, and there is a possibility of method name “collisions”, but this kind of problem is addressed in many other fields within computing (as well as being a general disambiguation problem), and the solution doesn’t have to involve rigid interface hierarchies.

Well not really. As I see in most of these languages nobody uses full namespaced method comparison to identify the method. If they did then you would be right, for the reasons I pointed to in my orignal article: your namespaced method is close to being a URI for it.

But in fact these languages don’t do this. they just look to see that there is a method that is named “Quack”. If there is it gets called as if it was clear that was it means was the sound. But why could a dog not have a “quack” method that meant to kill a cat? There would be no interface broken here. Just a clash of words, and we have those a lot in the english language. Things such as “bank” (the place you deposit your money at) and “bank” of a river… We disambiguate english because we take context into account, just as a programmer makes sure that when he gives objects to a method that will duck type on “quack” he makes sure never to give the method objects where “quack” means something else. Notice how this has trouble scaling though.

Anyway, I would be glad to be shown to be wrong. I just looked up a book on Ruby, and that confirmed my thinking. Do you have a pointer to a piece of code that could resolve the issue?

Especially when working w/ lots of people it seems like a good idea to be able to define interfaces strictly by setting up a Duck abstract class and having everybody that supports the duck interface inheriting from it rather than relying on people calling things the same thing. It seems like we’re taking a step back to have to manually write tests to check things that used to be done for us automatically.

Lets say I add a Swim method to my Duck class. Then I change the move method to call Swim instead of Fly under certain circumstances.

If I was using an IDuck interface, then I would get a compiler error on the Dog(Duck) class and know I needed to fix it.

If I am just using Duck, I wouldn’t know there was a problem with Dog(Duck) until either the unit tests catch it or, more likely, it crashes up at runtime.

If Dog’s Quack() method does not in fact, Quack() then it is not a valid quack. Dog() by it’s very nature has violated the contract for anyone who needs a Duck() but gets a Dog()

For example, in python - you have __getitem__(): If I created a class/object (class myob(object)) and over wrote __getitem__() to say, parse an XML stream and make the bios beep instead of simply returning a value from the local namespace - I am in violation of a very simple and basic contract within the language.

Name spaced methods are exactly that within Python. pkg.module.file.method() is a clear enough name space. Proper python module structure means that given your example, we should have:

animals.dog.sounds.quack()

animals.dog.actions.quack()

And so on. Which most python programs are smart enough to do - that’s the glorious nature of namespaces. If you have 14 Quack methods, they should each be contained within the proper namespace.

Man I have to get a threaded comment system

The original point of that article was, as you repeat above, that duck typing is implemented in many languages as just simple string comparison. So your
dog.quack() example, is said to implement the Duck interface just because both contain the “quack” methods. The problem is that someone else can just as well have created a “quack” method on the dog which does something completely different (perhaps a QUick Answer to A Cat: Kill). The fact that two strings are the same does not indicate they mean the same thing. For this you would need namespaced methods at the least. Then you could distinguish between animal.sound.quack() and animal.action.quack() perhaps. This would give your program a lot more generality already: it would mesh better with wider libraries, and depend less on subtle contextual knowledge of the code base. You can then see how going with full fledged URIs gives you the largest scalability for exchanging and meshing information.