The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

dtonnofer (12) [Avatar] Offline
#1
"The disadvantage is that duck typing alone is insufficient to implement more than one method of the same name that accepts different types of arguments. To do that, subtype polymorphism is needed once again. Clojure isn’t duck typed either, because Clojure doesn’t have the traditional concept of objects."

This confuses the hell out of me.

I always understood duck typing to mean "the type of the object basically IS the set of methods that it implements" - the methods may or may not be distinguished by their signature though; that depends on the implementation (or: "it depends on what the definition of 'set of methods' is")

So, in one language an Objects O1 and O2 may "duck type to the same type" if

O1.eat()
O2.eat(x)

exist. But this may not be the case in another language.

Another case:

O1.eat(Liquid l)
O2.eat(Solid s)

may "duck type to the same type" in one language, but not another.

"To do that, subtype polymorphism is needed once again."

Not necessarily - what one needs is, more generically, a type system.

"Clojure isn’t duck typed either, because Clojure doesn’t have the traditional concept of objects."

But Common Lisp can do it (http://en.wikipedia.org/wiki/Duck_typing#In_Common_Lisp)? Ok, I have to read more of this book.

Best regards,

-- David