I'll have the duck!

[Gregory Brown]

i actually understand what you are saying. still, a programming concept that
cannot be programmed is getting a bit metaphysical isn't it? maybe 'zen
typing' ;-)

Zen Typing: The sound of one duck quacking.

 

[Dumaiu]

7rans wrote:
....

Well, besides the fact that all code is the implementation of a way of
thinking, have you considered that you may be restricting the concept
arbitrarily? You say DuckTyping is like ElegantWay, and yet I was able
to use DuckType in psuedo-code in a meaningful way. I'd like to see you
do the same with ElegantWay. If what you say is true, how is that
possible?
.... # yadda-yadda

A valid semantic point--'ElegantWay' isn't a one hundred per-cent fit
for a likeness; but it made me laugh, and it's the sort of example I
was trying to think of but couldn't. Still, I am becoming increasingly
convinced that Mr. Black is right and duck typing cannot effectively be
modularized. To recap: Duck typing is the near absence of type
checking in the Ruby core language. It's a consequence of Ruby's
completely dynamic nature and the lack of distinction between method
definition and method call. I think Dave Thomas called attention to
and named it because its appearance was almost accidental and it was
interesting enough to deserve a head-on approach, or at least
consideration of one. But conceptually it's still an absence of
something (type validation)--a vacancy. A 'TypeChecking' module might
be useable, but one for duck typing would be a 'NoTypeChecking' module,
i.e., empty. You'd be trying to automate the act of leaving something
undone. Actually, it makes me think of the 'Acme:on't' module on
CPAN.
The elimination of any reliance on class hierarchies really would
leave you with a prototype-based model.

 

[Dumaiu]

Gregory Brown wrote:
....

Zen Typing: The sound of one duck quacking.

No, really, what *is* the sound of a duck typing?

 

[Chad Perrin]

Zen Typing: The sound of one duck quacking.

Shouldn't that be "the sound of one wing flapping"?

 

[ara.t.howard]

Zen Typing: The sound of one duck quacking.

touche!

-a

 

[M. Edward (Ed) Borasky]

Shouldn't that be "the sound of one wing flapping"?

This discussion brings back memories of the duck and the bird arguing in
"Peter and the Wolf". The bird asks the duck, "What kind of a bird are
you if you can't fly?" Well ... I've seen (mallard) ducks fly. They
really have to work hard to get airborne, though. This must have been a
fat domesticated duck.

"The secret word is Ruby".

 

[Matthew Smillie]

I have heard this term before too (or maybe I just thought of it
independently, not sure). I, too, prefer it to "duck typing" as it
more clearly demonstrates the core of the concept.

I nominate this as the new-name-for something-that-already-had-a-
name-and-didn't-really-need-a-new-one-but-this-one-is-better-so-
let's-make-everything-twice-as-confusing.

Surely AJAX already took that award?

 

[dblack]

Hi --

i was thinking about this on my ride home and recalled a term used in damian
conway's object oriented perl book (a fastastic book on oo programming btw.)
and a term he used way back then : 'interface polymorphism.' the more i
thought about it the more i like the term better than 'duck typing' because
it's closer in spirit to the idea of something being an acceptable object
merely by implimenting (via method_missing or whatever) a certain set of
behvaiours.

It sounds like a very useful term, but maybe not a synonym for duck
typing...? I'm not sure, but it doesn't sound like one would say:
Interface polymorphism is a way of thinking about programming in Ruby
[if I'm paraphrasing Dave Thomas correctly]. One might say: Ruby
offers interface polymorphism, which encourages duck typing [if I'm
using i.p. correctly :-]

My view is that we don't need to choose a winner-take-all term to
refer collectively to *everything* connected with Ruby's type
mechanism, including the way(s) programmers use that mechanism. We
can have a slightly whimsical but expressive term like "duck typing"
to refer to one aspect of it, and other terms to refer to other,
related things. I'm fond of "duck typing", "quasi-prototyped
objects", and various other terms -- all of which refer to something
of interest.


David

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
http://www.manning.com/black => RUBY FOR RAILS (reviewed on
Slashdot, 7/12/2006!)
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
(e-mail address removed) => me

 

[Paul Sanchez]

Dumaiu> Gregory Brown wrote:
Dumaiu> ...
Dumaiu> No, really, what *is* the sound of a duck typing?

I don't know, but I'm sure there's a pecking order. Don't faint when
you get the bill.

 

[Dumaiu]

i was thinking about this on my ride home and recalled a term used in damian
conway's object oriented perl book (a fastastic book on oo programming btw.)
and a term he used way back then : 'interface polymorphism.' the more i
thought about it the more i like the term better than 'duck typing' because
it's closer in spirit to the idea of something being an acceptable object
merely by implimenting (via method_missing or whatever) a certain set of
behvaiours.

Holy cow; the whole thread was worth it just for this. This is on
target: in ruby-talk 03608 matz in fact mentions as an illustration of
'implementation polymorphism' the Enumerable module, because the use of
each() is the only requirement defined for compatibility. I will posit
as a distinction that 'duck typing,' as we call it, is a description of
an innate behavior of the language, while 'implementation inheritance'
would be D. Conway's name for the general consequence of building
projects with this kind of model in mind.

 

[dblack]

Hi --

Holy cow; the whole thread was worth it just for this. This is on
target: in ruby-talk 03608 matz in fact mentions as an illustration of
'implementation polymorphism' the Enumerable module, because the use of
each() is the only requirement defined for compatibility. I will posit
as a distinction that 'duck typing,' as we call it, is a description of
an innate behavior of the language, while 'implementation inheritance'

(Do you mean 'interface polymorphism'?)

would be D. Conway's name for the general consequence of building
projects with this kind of model in mind.

Don't forget, though, that duck typing was originally intended as a
description of something that a programmer does. I've also always
tended to see it as a property of the language (i.e., Ruby as a
"duck-typed" language, as Jim Weirich has said) -- since the
method-call is always isolated from any ancestry checks and so forth
that surround it -- but, as I understand Dave's take on it, it does
refer at least equally to a programming attitude/style/philosophy (or
whatever the best term is).


David

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
http://www.manning.com/black => RUBY FOR RAILS (reviewed on
Slashdot, 7/12/2006!)
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
(e-mail address removed) => me

 

[Dumaiu]

This discussion brings back memories of the duck and the bird arguing in
"Peter and the Wolf". The bird asks the duck, "What kind of a bird are
you if you can't fly?" Well ... I've seen (mallard) ducks fly. They
really have to work hard to get airborne, though. This must have been a
fat domesticated duck.

I've heard that the turkey can fly. That suprised me; I would have
been sure that that one was too fat.

"The secret word is Ruby".

Actually, there are no corroborated reports of Ruby-powered ducks
spontaneously taking to flight. I would like to delay work on the
'LameWalk' and 'BlindSee' gems until we have confirming evidence for
this.

 

[ara.t.howard]

It sounds like a very useful term, but maybe not a synonym for duck
typing...? I'm not sure, but it doesn't sound like one would say: Interface
polymorphism is a way of thinking about programming in Ruby [if I'm
paraphrasing Dave Thomas correctly]. One might say: Ruby offers interface
polymorphism, which encourages duck typing [if I'm using i.p. correctly :-]

right. one would say something like

'make your methods accept interface polymorphic objects for maximum re-use'

eg

def m obj
p obj.foobar # takes any obj that responds_to? 'foobar' - NEVER do we check type
end

afaikt this is a concrete prescription for 'duck typing' that avoids
mentioning types!

My view is that we don't need to choose a winner-take-all term to refer
collectively to *everything* connected with Ruby's type mechanism, including
the way(s) programmers use that mechanism. We can have a slightly whimsical
but expressive term like "duck typing" to refer to one aspect of it, and
other terms to refer to other, related things. I'm fond of "duck typing",
"quasi-prototyped objects", and various other terms -- all of which refer to
something of interest.

indeed - still that 'type' bit is quite a cause for confusion.

cheers.

-a

 

[dblack]

Hi --

indeed - still that 'type' bit is quite a cause for confusion.

Don't take it too absolutely concretely on a word-by-word basis,
though. The "typing" in "duck typing" is a bit like the "bookkeeping"
in "creative bookkeeping"


David

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
http://www.manning.com/black => RUBY FOR RAILS (reviewed on
Slashdot, 7/12/2006!)
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
(e-mail address removed) => me

 

[ara.t.howard]

Don't forget, though, that duck typing was originally intended as a
description of something that a programmer does. I've also always tended to
see it as a property of the language (i.e., Ruby as a "duck-typed" language,
as Jim Weirich has said) -- since the method-call is always isolated from
any ancestry checks and so forth that surround it -- but, as I understand
Dave's take on it, it does refer at least equally to a programming
attitude/style/philosophy (or whatever the best term is).

hmmm. see, i don't think these two ideas are at odds because i agree with you
that 'duck typing' can't be implimented via a module (recall that it's this
conecpt the started the thread long, long, long ago!). what was bothering me
about that is the lack of a concrete term that can actually describe real ruby
objects in real ruby code. to say that they a specific object is 'interface
polymorphic' is a way of saying what tom was getting at - that the object will
respond_to some set of methods (potentially via method_missing) - and is,
therefore, an acceptable argument to some method while avoiding the nasty
'is_a' typing issue.

also, on further consideration, i'm thinking that duck typing is indeed more
of a concept and less a hard and fast set of coding constructs. consider

def m
yield :foobar
end

i'd say this is equal in spirit to

def m obj
obj.foobar
end

in the first case we simply do not check whether a block was given or, if it
was, if it accepts at least one argument. note that this example does not
involve an object whose interface may be checked. nonetheless i think it's in
the spirit of 'duck typing' to say that this method is 'duck typed' (bad term
in know) because we are asserting any preconditions on how it's called and
accept that unit-testing and runtime failures are our only tools to track down
errors in calling it.

contrast that to the second case where an actual object is passed to 'm' and
it's required to respond_to? the message 'foobar'. in this case we are also
thinking in 'duck terms' but we can also say that 'obj' is required to be
'interface polymorphic' to the set of objects that respond_to 'foobar' called
with no arguments. this __is__ something that can be verified (ignoring race
conditions inherent in dynamic languages with methods being added) and,
therfore, encapsulated in some sort of module.

in summary i'm suggesting 'interface polymorphism', or some cute short-hand
like PolyFace, as terminology for an implimentation which encapsulates the
process of ensuring/checking an object's method signatures/behaviours to
determine if that object is allowed to pass a gate or not.

regards.

-a

 

[ara.t.howard]

Hi --



Don't take it too absolutely concretely on a word-by-word basis,
though. The "typing" in "duck typing" is a bit like the "bookkeeping"
in "creative bookkeeping"

__except__ for the fact that 'type' is easily one of the most semantically and
emotionally loaded words for computer scientists - especially those coming
from strongly typed languages - so its use naturally (as a search on this list
will demonstrate) leads over and over to the people's thinking of 'duck
typing' as defining categories meeting 'is_a/can_be' type constraints and as
being something that can be written.

even though we all know the duck typing that can be named is not the real duck
typing.

sorry, couldn't resist ;-)

-a

 

[dblack]

Hi --

__except__ for the fact that 'type' is easily one of the most
semantically and emotionally loaded words for computer scientists -
especially those coming from strongly typed languages - so its use

I'd say "bookkeeping" is a pretty suggestive and loaded term for
accountants and tax people (But read below too.)

naturally (as a search on this list will demonstrate) leads over and
over to the people's thinking of 'duck typing' as defining
categories meeting 'is_a/can_be' type constraints and as being
something that can be written.

When it comes to the association between anything with "type" in it
and is_a?-style checking, there's a more fundamental (hypoduck?)
issue: namely, the tenacity of the assumption that type and class are
the same thing. I think that "duck typing" is an attempt to get
people away from that assumption -- but the problem is that the duck
typing concept, instead, gets reinterpreted to accomodate the
assumption. So one hears references to an object's "duck type", when
what's really being talked about is simply the object's type (i.e.,
the object's capabilities and behaviors at a given point in runtime).
And as long as one speaks of a "duck type", one implies that plain old
"type" refers to something else; and the usual candidate for that is
the object's class.


David

even though we all know the duck typing that can be named is not the real
duck
typing.

sorry, couldn't resist ;-)

-a

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
http://www.manning.com/black => RUBY FOR RAILS (reviewed on
Slashdot, 7/12/2006!)
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
(e-mail address removed) => me

 

[Chad Perrin]

I've heard that the turkey can fly. That suprised me; I would have
been sure that that one was too fat.

Wild turkeys can fly (badly). Domesticated, not so much. They do tend
to drown in the rain, though.

 

[James Britt]

...
When it comes to the association between anything with "type" in it
and is_a?-style checking, there's a more fundamental (hypoduck?)
issue: namely, the tenacity of the assumption that type and class are
the same thing. I think that "duck typing" is an attempt to get
people away from that assumption -- but the problem is that the duck
typing concept, instead, gets reinterpreted to accomodate the
assumption. So one hears references to an object's "duck type", when
what's really being talked about is simply the object's type (i.e.,
the object's capabilities and behaviors at a given point in runtime).
And as long as one speaks of a "duck type", one implies that plain old
"type" refers to something else; and the usual candidate for that is
the object's class.

If you poke around Lambda the Ultimate for a bit you soon learn that
notions of "type" are numerous and quite varied. The terminology gets
slippery fast.

 

[Hal Fulton]

I have heard this term before too (or maybe I just thought of it
independently, not sure). I, too, prefer it to "duck typing" as it more
clearly demonstrates the core of the concept.

I nominate this as the new-name-for something-that-already-had-a-name-
and-didn't-really-need-a-new-one-but-this-one-is-better-so-let's-make-
everything-twice-as-confusing.

I mentioned this term in ch 1 of _The Ruby Way_ (referencing
Damian Conway).


Hal