«

In the Method Redefinition thread, this explanation of Duck Typing is
offered ...

> What Duck typing is based mostly on realising what sort of operations
> you want to do with the object and testing for those operations,
> rather than testing for the class. As Dave is fond of saying: type and
> class aren't the same.

This is slightly different than my understanding of Duck Typing. I
would phrase it more like this:

Duck typing is based mostly on realising what sort of operations
you want to do with the object and just doing them, rather than
worrying if the object inherits from the proper base class or
interface.

I've heard others also explain duck typing in terms of explicitly
testing for particular methods and I feel that leaves the wrong
impression. If we say Ruby supports duck typing, then newcomers are
left with the impression that you need to do a lot of testing for
particular methods (which you don't).

I would call this an example of Duck Typing ...

class Dog
def talk
puts "Woof"
end
end
class Duck
def talk
puts "Quack"
end
end
[Dog.new, Duck.new].each { |a| a.talk }

... even though there is no explicit method testing going on. After
all, if it walks and talks like a duck ...

So, am I off base?

--
-- Jim Weirich http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

On Saturday, September 13, 2003, 10:23:16 AM, Jim wrote:

> [...]

> I would call this an example of Duck Typing ...

> class Dog
> def talk
> puts "Woof"
> end
> end
> class Duck
> def talk
> puts "Quack"
> end
> end
> [Dog.new, Duck.new].each { |a| a.talk }

> ... even though there is no explicit method testing going on. After
> all, if it walks and talks like a duck ...

> So, am I off base?

Not AFAIC. Testing for methods is one of those things that can sound
important in theory, but who ever programs like that? After all, if
the method you're after isn't supported, what are you going to do?
Choose another one?

Of course, in frameworks and libraries there is often some funny
meta-programming going on, but that's a special case, and it still
runs on the old assumption that you're confident of what the code is
doing.

Gavin

Meino Christian Cramer wrote:
> From:
> Subject: Re: Duck Typing
> Date: Sat, 13 Sep 2003 10:29:52 +0900
>
> Hi, first of all: I am very happy to have a programming language with
> such a communicative and friendly mailinglist!!!
>
> GREAT!
>
> (Whether it will be a good idea or not to mirror the posts into a newsgroup
> -- we will see. Previously I had made bad experiences, since my email
> postbox was overloaded with spam. Spammers do scan newsgroups for
> addresses... but this is quite another topic...)
>
> Back to the ducks !
>
>
>>Or even, more generally, left with the impression that there's an
>>on/off switch: if you say "is_a?" a lot, then you're not doing duck
>>typing, whereas if you say "respond_to?" a lot, then you are -- when
>>in fact it's really Ruby that's doing the duck typing, and you're
>>just deciding how to react to it.
>
>
> If both works: is_a? and respond_to? : What is the advance of one
> over the other beside the fact, that one has a cool name : "Duck
> typing"?
>
> Is one slower, less clean or ... ? I am just curious...

Don't misunderstand. David is saying that this is *some* people's
impression of what duck typing means.

Note the second part: "--when in fact it's really Ruby that's doing
the duck typing, and you're just deciding how to react to it."

It's not a coding style or technique; it's an attribute of the
language.

Hal

Meino Christian Cramer wrote:

> If both works: is_a? and respond_to? : What is the advance of one
> over the other beside the fact, that one has a cool name : "Duck
> typing"?
>
> Is one slower, less clean or ... ? I am just curious...
>
>

You really shouldn't use #is_a? or #respond_to? much at all. That's not what
duck typing is about.

Just write your method to use methods that the passed in object should
have, by
the contract of the method. Then test to make sure your program works.

Excessively using #is_a? and #respond_to? is essentially trying to turn ruby
from a dynamically typed language into an ad-hoc statically typed language,
which isn't in the spirit of duck typing at all.

The only real reason you should be using these methods is if you need to
take different actions depending on which of several methods is available.
If you're just checking whether the only method you use exists or not,
you're
just doing extra work most of the time. The interpreter will tell you if it
isn't there.

It can be a confusing issue if you haven't read the discussions before.
There
was a big one some weeks back, so it might be worth it to read the ruby-talk
archives to clear some stuff up without duplicating all of it again.

Cheers.

- Dan

Dan Doel <> wrote:
>
> The only real reason you should be using these methods is if you need to
> take different actions depending on which of several methods is available.

Even then, there are cases where you can use the (cleaner or not
depending on your pov and how many times you have to do it) alternative
of creating a common name for the methods, and aliasing it to the
appropriate method within each class. In java terms, you're using open
classes to retroactively derive from a common interface.

martin

On Sat, 13 Sep 2003 09:23:16 +0900
Jim Weirich <> wrote:

> In the Method Redefinition thread, this explanation of Duck Typing is
> offered ...
>
> > What Duck typing is based mostly on realising what sort of operations
> > you want to do with the object and testing for those operations,
> > rather than testing for the class. As Dave is fond of saying: type and
> > class aren't the same.
>
> This is slightly different than my understanding of Duck Typing. I
> would phrase it more like this:
>
> Duck typing is based mostly on realising what sort of operations
> you want to do with the object and just doing them, rather than
> worrying if the object inherits from the proper base class or
> interface.
>
> I've heard others also explain duck typing in terms of explicitly
> testing for particular methods and I feel that leaves the wrong
> impression. If we say Ruby supports duck typing, then newcomers are
> left with the impression that you need to do a lot of testing for
> particular methods (which you don't).

I agree completely.

> I would call this an example of Duck Typing ...
>
> class Dog
> def talk
> puts "Woof"
> end
> end
> class Duck
> def talk
> puts "Quack"
> end
> end
> [Dog.new, Duck.new].each { |a| a.talk }
>
> .. even though there is no explicit method testing going on. After
> all, if it walks and talks like a duck ...
>
> So, am I off base?

No. That is how I think of Duck Typing as well. Just call the methods.
Don't bother with method existence checking, Ruby does it for you. (By
raising NoMethodError)

Jason Creighton

On Sat, 13 Sep 2003 17:13:17 +0900
Hal Fulton <> wrote:

> > Is one slower, less clean or ... ? I am just curious...
>
> Don't misunderstand. David is saying that this is *some* people's
> impression of what duck typing means.
>
> Note the second part: "--when in fact it's really Ruby that's doing
> the duck typing, and you're just deciding how to react to it."
>
> It's not a coding style or technique; it's an attribute of the
> language.

I disagree, with some proof by counterexample.

The assertion is this: Ruby does not have an attribute of the language
that is "duck typing", it is merely a style of coding.

1) By the definitions given in this thread, duck typing is taking a
given object and pretending it's the type you want, and letting
the language give you an error if it doesn't work like you
expected.

(If you disagree with this definition, you can provide an
alternate one, but arguing over definitions is useless.)

2) We can accomplish this because the language lets us specify a
call to a method without checking the type at "compile-time"
(parse-time, in ruby's case):

x.a # This call is not validated until it is executed

3) We can further accomplish this because the language does not
require we specify types to a methodcall, thus allowing us to
pass any object.

4) Statements 2-3 are the only functional provisions necessary for
accomplishing the practice in statement 1.

5) Many non-Ruby dynamic languages provide the functionality in
statements 2-3. Examples include JavaScript, Common Lisp (CLOS),
Scheme, Python, Perl, and PHP.

6) These languages make no special provisions for duck typing, but
it can be practiced, because the functional requirements of 2-3
are met.

7) In any of the given languages, and Ruby, one can choose to check
types or not check types.

Therefore: Based on statements 1-5, "duck typing" is not specific to
ruby, but rather made possible by the dynamic nature of a language.
Based on statements 6-7, duck typing is neither specifically provided
for nor compulsory, so it is not an attribute of the language.

Thus, because it can be practiced, or not practiced; in ruby, or in
other languages; it must be a _style_ available in dynamic languages,
rather than a specific feature of a particular language.

--
Ryan Pavlik <>

"Damn ye and ye black ops mind games!" - 8BT

On Sun, 14 Sep 2003 04:32:49 +0900
Michael Campbell <> wrote:

> > Therefore: Based on statements 1-5, "duck typing" is not specific
> > to ruby...
>
> That was never asserted.

Yes, but it _was_ asserted that it was a language attribute of ruby,
when you can practice it in other languages, which have no specific
provisions, any mention of "duck typing", or common practice thereof.

(Although, in JavaScript, and most prototype-based languages, you
usually practice 'duck-typing' because that's the way things are.
Pure prototype-OOP has no class, just an object that acts in a
particular manner---in this case, you could probably consider it a
feature of the language.)

--
Ryan Pavlik <>

"Damn ye and ye black ops mind games!" - 8BT

Ryan Pavlik wrote:

>Yes, but it _was_ asserted that it was a language attribute of ruby,
>when you can practice it in other languages, which have no specific
>provisions, any mention of "duck typing", or common practice thereof.
>
>(Although, in JavaScript, and most prototype-based languages, you
>usually practice 'duck-typing' because that's the way things are.
>Pure prototype-OOP has no class, just an object that acts in a
>particular manner---in this case, you could probably consider it a
>feature of the language.)
>
>

Duck typing may not be a "feature" of Ruby, but it's definitely supported by
Ruby. It's also very well supported by Python, Perl, JavaScript, and
I'm sure
many other languages. The difference with Ruby is that Dave Thomas hangs
out here more and he's the one who said it originally.

Ruby does have some provisions that make it more supportive of duck typing,
though. For example, as I understand it, in Smalltalk (which I'm still
learning),
you define all your methods when you're building the program, and then all
that is fixed. You can't, for example, make an object of class Object
and then
write custom methods for that one object. So objects and types are more
dynamic in Ruby than in, say, Smalltalk, for example.

This, of course isn't exclusive to Ruby. As I recall, JavaScript allows you
to add methods to arbitrary classes or objects. But, as I said, Dave Thomas
hangs out here, which is why Ruby people talk about duck typing and
JavaScript people don't.

Cheers.

- Dan

Mark Wilson <> wrote:

> I've seen some adoption of the term among python people recently.

What ? They stole that too ?? :>

--
Luc Heinrich -