Duck Typing in other languages?

Ruby
1

Heya,
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/78502
is now a bit older than four years :wink:

Bit long, sorry, my “real” question is on the bottom of
this … anyway :slight_smile:

I think i get that with duck typing you dont care what
class/type something is. You ask it if it reponds_to?
something (and thus has a method)

It sounds a bit as if classes become less important than
behaviour (i think that’s a good notion anyway) and
is thus a lot more flexible in general. So far so fine.

When I lately asked on an IRC channel for a prototype based
language, I unfortunately didn’t really get the answer I hoped
for (how that language handled “duck typing”) but actually
it was quickly pointed out that duck typing is used in other
languages a lot too, maybe with different names )and for
static languages with a bit more rigid structure).

One definition that kept up was “late bound” (I admit freely,
duck typing would be approximately 100x easier to understand
than “late bound”, IF this refers to the same concept)

Smalltalk and Self would be examples for late bound concept.

Java has dynamic class loading and virtual calls (checked at
class loading time and checked on interfaces) but it seems
very rarely used (and, it seems you have to do a new
abstract class? How strange is this to create a totally
new class just to get to this behavioural concept?? But
then again I may be totally wrong :slight_smile: )

Basically it seems to boil down (for me) to message sends
and a class/type “less” approach where the object just
adapts to a job, instead of satisfying a compiler… :wink:

Ok now to my question!

What is the difference between ruby’s approach to classes
and duck typing compared to prototype based languages which
seem to have an even looser model (i.e. a less rigid class
vs object distinction and their usage of prototypes
“adapting” to a problem from the “bottom-up” ?)

Ah and if I forgot something about duck typing or similar
in other languages - maybe its interesting - please someone
feel free to point that out!

2

On 8/29/07, Marc H. [email protected] wrote:

It sounds a bit as if classes become less important than
behaviour (i think that’s a good notion anyway) and
is thus a lot more flexible in general. So far so fine.
100% aligned

When I lately asked on an IRC channel for a prototype based
language, I unfortunately didn’t really get the answer I hoped
for (how that language handled “duck typing”) but actually
it was quickly pointed out that duck typing is used in other
languages a lot too, maybe with different names )and for
static languages with a bit more rigid structure).
Well maybe I understand incorrectly but I would say by machanisms like
adding behavior to objects (I really like the term behavior here)
Maybe my ideas might interest you, they are expressed here:
Smalltalking about Ruby: Classless Ruby, a Paradigm Change?
you will see how I got rid of classes completely, in Ruby.

One definition that kept up was “late bound” (I admit freely,
duck typing would be approximately 100x easier to understand
than “late bound”, IF this refers to the same concept)
I think not really, I would say late binding is extremely useful for
the agility of a language but behavior could be fixed at compile time
without any class or is_a? concept and we still would have duck_typing
objects, but I feel that without late binding it is less fun, maybe
not even worth it, hmm that is food for thaught.
It would be nice if we could just assume Late Binding anyway :wink:
Basically it seems to boil down (for me) to message sends
and a class/type “less” approach where the object just
adapts to a job, instead of satisfying a compiler… :wink:
Yup and in the end it might not even matter if this behavior was
created by instantiation from a class or not, maybe you should have a
look at this too:
http://www.iam.unibe.ch/~scg/Archive/PhD/schaerli-phd.pdf
It is about Traits, anyway the way how to induce behavior into objects
is a very interesting field, strictly speaking it is not 100% bound to
duck typing as long as one is not hindered by Compiletime (or even
Runtime) checks looking at labels sticked onto objects, right?

Cheers
Robert

3

On 8/29/07, Marc H. [email protected] wrote:

Ah and if I forgot something about duck typing or similar
in other languages - maybe its interesting - please someone
feel free to point that out!

Another place I’ve noticed similar functionality is with
templates/generics in C++/Java. You write code that doesn’t care
about the (template/generic) classes/types. You write code for
objects of template/generic classes that respond to a set of methods
that you use. Compared to duck-typing in ruby, the main difference is
that concrete classes that you want to use for these template/generic
classes must be determined at compile-time. And of course
template/generic code is extremely ugly because it has to look like
static typing even those the types are variable. Also, with
template/generic code, the code is replicated for each class/type
combination, where with duck-typing this is not needed since finding
the methods occurs at run-time.

4

Marc H. [email protected] wrote:

I think i get that with duck typing you dont care what
class/type something is. You ask it if it reponds_to?
something (and thus has a method)

Duck typing is not formally defined. If it means similar
interfaces, it can be inferred:

$ ocaml
let duck ob arg = print_int (ob#meth arg);;
val duck : < meth : 'a → int; … > → 'a → unit =

The type inference finds that ob is an object with the method
meth which returns an integer. There is even polymorphism in
the argument allowed. I wonder if functors qualify as duck
typing on a more general level.
Benedikt