Hi –
On Thu, 27 Jul 2006, [email protected] wrote:
to
something of interest.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
On Thu, 27 Jul 2006 [email protected] wrote:
whimsical
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
Hi –
On Thu, 27 Jul 2006, [email protected] wrote:
including
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
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
On Wed, 26 Jul 2006 [email protected] wrote:
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 W. 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
[email protected] wrote:
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.
–
James B.
“Blanket statements are over-rated”
Jake McArthur wrote:
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
On Thu, Jul 27, 2006 at 12:05:06AM +0900, Dumaiu wrote:
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.
[email protected] wrote:
even though we all know the duck typing that can be named is not the
real duck
typing.sorry, couldn’t resist
Haha… well, if you can quote Lao Tzu, I can quote
Confucius. I ran across this quote from him last
year (no kidding) and it reminded me of duck typing:
“If an urn does not have the properties of an urn,
can it truly be said to be an urn?”
Shades of Plato, actually…
Hal
On Thu, Jul 27, 2006 at 04:50:04PM +0900, Mc Osten wrote:
Dumaiu [email protected] wrote:
No, really, what *is* the sound of a duck typing?I suppose the very same a human does when typing. However, probably what
it types would be less meaningful.
Not to the duck.
On 7/26/06, Hal F. [email protected] wrote:
year (no kidding) and it reminded me of duck typing:
“If an urn does not have the properties of an urn,
can it truly be said to be an urn?”
To which, of course, the answer is “no, it hasn’t urned the right”
martin
Dumaiu [email protected] wrote:
No, really, what *is* the sound of a duck typing?
I suppose the very same a human does when typing. However, probably what
it types would be less meaningful.
On Tue, Jul 25, 2006 at 08:14:59PM +0900, Christian N. wrote:
can find some material on that, i think you’ll find it interesting.
While you’re at it, have a look at Slate, that also removes single-dispatch.
Ron J.
–
Christian N. [email protected] http://chneukirchen.org
CLOS (Common Lisp Object System) has multi-dispatch too.
It is more powerful than smalltalk or ruby’s message based OOP
approach. It is also hard to design in, if you aren’t used to it.
Given that some people coming from static languages are still
wrestling with plain old duck typing, I think it would be overkill for
ruby, and hard on a lot of people. It’s just not ruby’s niche.
Jürgen
On Thu, Aug 03, 2006 at 12:01:50AM +0900, Jürgen Strobel wrote:
“late”. And IMHO exception handling was one of the better points when
going from C to C++. Think of duck typing as yet another technique not
to litter your code with error checking, but still do it
somewhere/sometime. You do handle C++ exceptions too, do you, if not
neccessarily right next to throwing them?I repeat: duck typing is not to produce bombing out code, but a new*
way to handle dynamic and flexible type validation “late”, with the
objective to ease development and produce clean code.
I’d say that duck typing is more a means of allowing you to defer
rigidity until it’s actually beneficial. It has little or nothing to do
with delaying validation, and everything to do with avoiding the
unfortunate circumstance of having to validate before it’s convenient
for your code to have something to validate.
On Tue, Jul 25, 2006 at 01:05:11PM +0900, Dumaiu wrote:
runtime errors. For Ruby, where every error is runtime, duck typing
is the raw form of its behavior, and should be recognized as quickly as
possible, because it isn’t always good. At its utmost, duck typing is
the total absence of validation. You are saying that nothing about
your client’s program is worth trying to predict, that ‘if it works, it
works,’ and if it doesn’t, he’ll know because it just blew up.
No. That’s not duck typing, that is shoddy programming.
You may have a rescue clause right after your doubtful code,
or somewhere else upwards in your call stack. Or it might be
guaranteed by application semantics (as opposed to static typeing)
that your object can handle the messages sent to it.
My take on duck typing:
Neither of them requires that a program may blow up.
Hmm. I see where type-checking came from. As far as Ruby best
practices go, I think ‘duck typing’ just means using respond_to?() more
than kind_of?() and include?(). If you really wanted to, dumping class
use entirely and turning Ruby into a prototype-based language wouldn’t
be too hard: you’d use Object::new() only, define only singleton
methods, and extend objects with clone(); and if you wanted to
delegate, you’d keep an array of references of “parent” objects,
Perl-style.
Sometimes it might be better to use #responds_to? early, and many
people will still consider this duck typing. It may be less “pure”
than handling NoMethodError, but it might be just the right tool
depending on your situation.
Even #kind_of? can have its merit in certain situations. I wouldn’t
call code using it to rely on duck typing though, but that’s not a bad
thing per se.
Prototype based languages are tangential to this, and need not be
drawn into this discussion here.
Personally, I feel that Ruby needs more, rather than less, type
safety, to balance its natural inclination otherwise and because no
amount of ‘duck typing’ disaffirms that erroneous behavior is best
caught as soon as possible. But I don’t think anyone would advocate a
return to rigid inheritance checking, which realization the deprecation
of type() notably indicates.
By your argument, exceptions are bad too, because they catch errors
“late”. And IMHO exception handling was one of the better points when
going from C to C++. Think of duck typing as yet another technique not
to litter your code with error checking, but still do it
somewhere/sometime. You do handle C++ exceptions too, do you, if not
neccessarily right next to throwing them?
I repeat: duck typing is not to produce bombing out code, but a new*
way to handle dynamic and flexible type validation “late”, with the
objective to ease development and produce clean code.
-Jürgen
On Wed, Aug 02, 2006 at 11:32:13PM +0900, Jürgen Strobel wrote:
CLOS (Common Lisp Object System) has multi-dispatch too.
It is more powerful than smalltalk or ruby’s message based OOP
approach. It is also hard to design in, if you aren’t used to it.
Given that some people coming from static languages are still
wrestling with plain old duck typing, I think it would be overkill for
ruby, and hard on a lot of people. It’s just not ruby’s niche.
I agree. If we were going to go that route, we’d probably want to give
Ruby a functional syntax, at which point we’d just be using Lisp anyway.
Let’s keep Ruby its own language.
Duck typing appeals to me specifically because it lets me say that I
have a class of People and I can treat them as a list without having
to do specific inheritence, et c.
Also, on the other-languages discussion, IO is also a
prototype-based-OO language.
M.T.
On Thu, Aug 03, 2006 at 01:07:40AM +0900, Matt T. wrote:
Also, on the other-languages discussion, IO is also a
prototype-based-OO language.
Isn’t that language called Io, like the natural satellite, and not IO,
like input and output? I ask because I’m not sure – and I’m too lazy
to Google it right now.
On 8/2/06, Chad P. [email protected] wrote:
I’d say that duck typing is more a means of allowing you to defer
rigidity until it’s actually beneficial. It has little or nothing to do
with delaying validation, and everything to do with avoiding the
unfortunate circumstance of having to validate before it’s convenient
for your code to have something to validate.
That is one of the most concise statements on the benefits of
duck-typing I’ve ever read. Thanks, Chad!
Jacob F.
Jürgen Strobel [email protected] writes:
wrestling with plain old duck typing, I think it would be overkill for
ruby, and hard on a lot of people. It’s just not ruby’s niche.Jürgen
CLOS has classes, though.
On Thu, Aug 03, 2006 at 12:39:38AM +0900, Chad P. wrote:
By your argument, exceptions are bad too, because they catch errors
I’d say that duck typing is more a means of allowing you to defer
rigidity until it’s actually beneficial. It has little or nothing to do
with delaying validation, and everything to do with avoiding the
unfortunate circumstance of having to validate before it’s convenient
for your code to have something to validate.
We seem to agree even if you think we don’t.
“avoiding … validation before it’s convenient” vs. “delayed
validation”.
“defer rigidity” vs. “dynamic and flexible type validation”
Now where is the difference apart fom wording?
-Jürgen
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs