On 6/27/07, Trans [email protected] wrote:
Beyond symbol_or_string.to_s, and the like, how extensively do we ever
see duck-typing playing a roll in our code?
I do not know Tom, one application springs into mind, I am generating
iptables commands from a DSL. The outpout is done via #<< to an object
(defaulting to $stdio) for testing I just set that object to an array.
A rare occasion, yes, but a very serious feature indeed.
That’s a pretty good example. It’s easy to effect because it’s based
on the single method #<<. And I’ve used it too.
Note the subtle shift here, the TYPE consists of a set of expected
behavior, in this case the single method #<<. This set of behavior is
like a job requirement. This type arises out of the USE of the object
by somone, not the implementation of the object. This is the
‘role-based’ typing I wrote about years ago in
One way of thinking about this is that there’s no need to constrain
how we think about ‘type’ to the class implementation hierarchy.
Constraining subclasses to be subtypes which struggle to meet the
Liskov Substitution Property might be the only way of thinking about
things in C++/Java, but it’s overly constraining, and even in those
other languages, it turns out to be a weak version of reality, there
are counterexamples of LSP even in Java and C++.
If you’re up for a rather long discussion about what LSP does/doesn’t
should/shouldn’t mean. And what a subtype is/isn’t.
Look at Alistair Cockburn’s analysis in the c2 page of whether or not
Square is a subtype of Rectangle (or the other way around).
Granted Class-base typing can be too constricting, just as respond_to
typing can be too granular. What would be optimal is something more
fluid, that can encompass them or any shade inbetween --a way to
specify what something represents, not just how it’s encoded.
Ummm, how about rdoc commentary.
Seriously, it seems to me that the best that even a strongly typed
languages can do isn’t much beyond syntactic type matching. There’s
more to avoiding errors than just having matching signatures between
caller and callee. A lot of the discussion on the c2.com (Ward’s
wiki) site is about how LSP falls down when the behavior changes even
though the signature doesn’t.
Sometimes the right approach is that of a surgeon, assisted by a
I’m talking about the close coupling (temporal and otherwise) between
codeing and testing which is found in all of the agile methods.
In other words don’t overthink things, take a shot based on general
knowledge and be prepared to deal with the consequences.
example above. We want two arguments, an Integer which represents an
index and a string which represents a file. Now there are a few
ways to represent a file actually, File.open(), Pathname.new(),
probably others. And yet, duck-typing isn’t going to do a bit of good
if one of those is passed in instead of the String representation.
No fair, you’re getting back to the OPs example
Seriously, I think that discriminating actual positional arguments
based on type discrimination is a separate issue, and I’m not sure
that it’s that useful.
Positional parameters make a lousy technique for expressing variability.
Nice. You were able to put duck-typing to better work for us. But I
want to emphasis my point here. You were able to do this by thinking
in terms of types. When accepting parameters, you still think “a
File-like thing”. With you’re code it can now be a String or a File.
I’d argue that it’s not really a file-like thing, it’s an object which
represents a sequence and which has a method << which adds an object
to the end of the sequence.
It’s not really limiting to specify types in method interfaces. We are
rather limited by not having good means to properly specify those
Once again, I’d suggest rdoc commentary, and test cases, rather than
trying to come up with a means of ‘properly’ specifying such types.
Particularly if ‘properly’ means something which would produce a
compiler warning, which in the case of Ruby would appear only
milliseconds before the exception which would be thrown if the type
specification error wasn’t a false negative and the compiler didn’t
notwithstanding I feel more like “using protocols”.
Ruby gives you the power to implement those protocols but you have to
implement some of them yourself
To be honest I’m not really that fond of the expression either, for
one thing I get the impression that it makes people think too much
about everything being a duck, instead of geese, hammers, etc.
I think Ruby is a great experiment in this area, and undoubtedly it
shows some promise.
Smalltalk? 35 years ago, I think Rick confirmed the now famous Alain
Kay quotation about Smalltalk beating Java, but being called Ruby.
Actually that was Kent Beck not Alan.
I’d say that mixins have a significant impact on being able to combine
implementation while breaking out of the tyranny of a hierarchy.
Mixins do tend to help cluster protocols, but they don’t REALLY
provide anything more in the way of typing.
Consider some of the recent discussions about Array vs. Hash and the
reject/select methods. Just because two classes include Enumerable
doesn’t make their instances substitutable for each other in all
I’m not really arguing against duck-typing. I just don’t think it’s
necessarily in opposition to specifying optional parameter types. If
the the whole duck-typing idea was more deeply pursued we might even
find it quite intuitve to do so, using Mixins:
def foo(a < Enumerable)
But see the warning above.
In this way we can see what kind of “duck” a parameter requires.
This isn’t perfect however because of possible side-effects and
conditionals, which can skew the results. We would require a dry-run
mode and some dynamic means of dealing with condition statements (eg.
a decoy would split down both paths of any condition). It’s not an
easy problem, but I don’t think it is impossible either --at least not
Well if you think so , go ahead and pursue it. I think that it’s
a pretty big achilles heel.
I’m not sure how this would be used other than as part of a
development tool, you wouldn’t want to do this at runtime would you?
Why not just use the regular test tools with the real objects. This
seems to me like an actor sending a cardboard cutout of himself to an
audition instead of going himself.
My blog on Ruby