Asp Forum - duck-typing allows deeper polymorphism

Eric Mahurin

6/10/2005 11:43:00 AM

I've seen many posts on what duck-typing is, that Ruby doesn't
need static typing, that duck-typing results in easy to read
code, etc (and others that want static typing). What I haven't
seen much of is what advantage duck-typing gives to a method
over conventional polymorphism. This is a follow on of my
previous thread "making a duck". I would like to get on my
soapbox and talk about it a little...

With the polymorphism of other languages, class hierarchy is
very important. When you specify an argument can take a
certain class, you are saying that it can also take anything
derived from it (or implementing the same interface if the
language has that concept).

With duck-typing, class hierarchy and class names are not
important. Every argument that is duck-typed (built-in methods
unfortunately usually aren't) effectively has its own "type".
The "type" of an argument is defined by what methods it needs
to respond to and any "type" requirements of those methods
arguments or return values. If an argument has no method
requirements, then that argument could be anything. With an
argument needs to respond to just one method, you can think
about making an object on-the-fly that meets that one
requirement. That one method could easily be made from a
method of another object - including Proc#call (arbitrary
code). With an argument that needs to respond to more methods,
you can still do the same (mapping multiple methods), but at a
certain point it may become too cumbersome.

As an example, suppose you have 2 methods in an object that
take String-like things. With conventional polymorphism, you
might abstract this up to anything indexable to encompass
String and Array. With duck typing, you don't need to do
anything explicit - just continue thinking of it like a String
when coding the methods. Let's say one of the methods reads
from its "String" argument using only the [] method. You could
easily use a String, Array, Hash, or more powerfully a Proc.
The second appends to its "String" argument using the <<
method. Here you could easily use a String or Array. In both
of these cases, you could grab any method of any object and map
it to new object (and name the method appropriately). Of
course the most flexible would be mapping a Proc#call - do
whatever you want in that Proc.

To get maximum benefit from duck-typing, several things will
help out:

* For every duck-typed argument, document what the duck-type is
- what methods it needs to respond to and what the duck-type
requirements are on those method arguments and return values.
To help out with this it would be nice if we had something in
rdoc for this - but I don't know what.

* A convenient way to create objects on-the-fly for duck-typed
arguments. Some implementations were given in the thread
"making a duck".

* Don't overload your methods. As soon as you overload a
method to allow multiple "types" for an argument (and do
different things based on the "type"), you are not doing strict
duck-typing. At a minimum when you overload, you have to ask
whether an object responds to a certain method to determine
what to do. Doing this can limit what you can pass in due to
ambiguities as to what the "type" is. If you make a method
that can take a flying-thing, a swimming-thing, or a
walking-thing, what should this method do when it receives a
duck - because a duck can fly, swim, and walk?

* The fewer methods that a duck-typed argument responds to the
more flexibility you have in what you can pass to to it. Many
arguments may just require one method of the argument which is
ideal (next to zero methods of course). One method allows easy
on-the-fly object creation as described above.

* Use duck-typing everywhere!

__________________________________
Discover Yahoo!
Have fun online with music videos, cool games, IM and more. Check it out!
http://discover.yahoo.com/o...

7 Answers

Robert Klemme

6/10/2005 11:54:00 AM

Eric Mahurin wrote:

<snip>a lot of good stuff</snip>

> * Use duck-typing everywhere!

Well quacked! ;-)

Kind regards

robert

Ara.T.Howard

6/10/2005 2:00:00 PM

Eric Mahurin

6/10/2005 3:07:00 PM

--- "Ara.T.Howard" <Ara.T.Howard@noaa.gov> wrote:

> On Fri, 10 Jun 2005, Eric Mahurin wrote:
> > To get maximum benefit from duck-typing, several things
> will
> > help out:
> >
> > * For every duck-typed argument, document what the
> duck-type is - what
> > methods it needs to respond to and what the duck-type
> requirements are on
> > those method arguments and return values. To help out with
> this it would be
> > nice if we had something in rdoc for this - but I don't
> know what.
>
>
> this shows, right up front in the method, that the method
> takes an argument 'x'
> which must respond to 'upcase', and 'downcase'. an exception
> is thrown if
> something that does not respond to both these methods is
> passed in:
>
> harp:~ > cat a.rb
> require 'parseargs'
> include ParseArgs
>
> def method(*argv)
> pa = parseargs(argv){
> arg :x, :ducktype => %w(upcase downcase)
> }
> p pa.x.upcase.downcase
> end
>
> method '42'
>
> harp:~ > ruby a.rb
> "42"
>
>
> note that this could be parsed via rdoc quite easily.

I don't really like this because:

a. if you put this all over the place, it will significantly
degrade the code readability

b. efficiency. You've added unnecessary checking. Why not let
the code raise the exception when it doesn't find the method?

c. this may actually hinder some duck typing. In your example
above, you might make the method not always call both upcase
and downcase (maybe another boolean arg might control that).
If the caller has enough control, he could call the method with
an object that just responds to one of them. But parseargs
unnecessarily prohibit that.

d. this only starts to capture the true duck-type. To really
describe it, you would need a more elaborate system which
included conditions when the arguments methods are called,
description of the requirements for the arguments to those
methods, and what the duck-type should be for return values of
those methods. If you are able to implement that, then you
really are going to make the first problem even worse - code
clutter.

I think the description of the duck-type only belongs in the
documentation. I don't really see the advantage of putting it
in the code.

> > * A convenient way to create objects on-the-fly for
> duck-typed
> > arguments. Some implementations were given in the thread
> > "making a duck".
>
> two ways exist to do this easily using parseargs:
>
> * coerce the object into another type
>
> harp:~ > cat a.rb
> require 'parseargs'
> include ParseArgs
>
> def method(*argv)
> pa = parseargs(argv){
> ra :x, :ducktype => %w(upcase downcase), 'coerce' =>
> 'to_s'
> }
> p pa.x.upcase.downcase
> end
>
>
> method 42.0
> harp:~ > ruby a.rb
> "42.0"
>
>
> * 'convince' the object that it can behave like a duck by
> extending on the fly
>
> harp:~ > cat a.rb
> require 'parseargs'
> include ParseArgs
>
> def method(*argv)
> pa = parseargs(argv){
> ra :x,
> :ducktype => %w(upcase downcase),
> :convince => lambda{|obj|
> class << obj
> def upcase; '42'; end
> def downcase; '42'; end
> end
> }
> }
> p pa.x.upcase.downcase
> end
>
>
> method Object::new
>
> harp:~ > ruby a.rb
> "42"
>
> or via a module which should extend the object on the fly for
> increased
> duck-i-ness:
>
> harp:~ > cat a.rb
> require 'parseargs'
> include ParseArgs
>
> module Ducky
> def upcase; '42'; end
> def downcase; '42'; end
> end
>
> def method(*argv)
> pa = parseargs(argv){
> ra :x,
> :ducktype => %w(upcase downcase),
> :convince => Ducky
> }
> p pa.x.upcase.downcase
> end
>
> method Object::new
>
> harp:~ > ruby a.rb
> "42"

I'm talking about the caller making the duck, not the method
being called. Something like this:

# make call act like xyz for this new arg
method_where_arg_responds_to_xyz( proc{...}.duck(:xyz,:call) )

> > * Use duck-typing everywhere!
>
> hear hear!

I guess I really should have said "use pure duck-typing
everywhere". What I mean by that is that methods shouldn't try
to categorize or test the capabilities of their arguments at
all - don't use #respond_to?, #class, etc. I used to use
#respond_to? occassionally to make overloaded methods, but am
now convinced to go the pure duck-typing route - splitting
overloaded methods into multiple methods.

__________________________________
Discover Yahoo!
Have fun online with music videos, cool games, IM and more. Check it out!
http://discover.yahoo.com/o...

Ara.T.Howard

6/10/2005 5:04:00 PM

Eric Mahurin

6/10/2005 5:51:00 PM

--- "Ara.T.Howard" <Ara.T.Howard@noaa.gov> wrote:

> TWENTY_SIX_KEWORDS_AT_ONCE = ('a' .. 'z').to_a
>
> def method argv
> pa = parsearges(argv){
> required_argument 'foobar'
> keywords TWENTY_SIX_KEWORDS_AT_ONCE
> }
> end

I could see this being useful. But, I don't care for
additional "type" checking over what the code already does.

> > b. efficiency. You've added unnecessary checking. Why not
> let
> > the code raise the exception when it doesn't find the
> method?
>
> it's only added if you like. you don't have to use the
> duck-typing feature at
> all. besides, you approach is simply not valid for some
> cases (like nearly
> all the code i have around here) that do things like
>
> def method job, logger
>
> job.submit_job_to_queue_that_takes_three_to_five_days
>
> logger.info{ "job <#{ job.name }> finished with <#{
> job.status }>"
>
> end
>
> now, if logger doesn't repsond to 'info' or job doesn't
> respond to 'name' and
> 'status' i'll blow up and not log a job that just took three
> days to run.
> bummer.

So you just want the check to occur earlier than when the code
makes the check. That sounds like a reasonable usage when the
method can take a very long time (> a few minutes).

> >> hear hear!
> >
> > I guess I really should have said "use pure duck-typing
> everywhere". What I
> > mean by that is that methods shouldn't try to categorize or
> test the
> > capabilities of their arguments at all - don't use
> #respond_to?, #class,
> > etc. I used to use #respond_to? occassionally to make
> overloaded methods,
> > but am now convinced to go the pure duck-typing route -
> splitting overloaded
> > methods into multiple methods.
>
> again - this notion ignores all notion of temporality and
> cost. what if you
> were paying for a slot on a super-computer and wouldn't be
> able to get in
> again for three weeks and had a pending paper due?

Maybe you could think of duck-typing as when functionally a
method doesn't need to categorize the "type" of any of its
arguments or overconstrain what its argument capabilities
should be. Implementation-wise, you may use respond_to?,
class, etc but it should have equivalent functionality to some
implementation that didn't use these. I think this early
checking you do would just be an implementation thing. Another
case I can think of is when you might have a more efficient
(i.e. C) implementation for a specific class. For example, if
you wanted to make a duck-typed Regexp class, you might special
case the String class:

def Regexp
def match(sequence)
if String===sequence
super # fast C implementation
else
# a less efficient pure duck-typed implementation
end
end
end

I think it would be great if more of the built-in classes were
duck-typed like this.

__________________________________
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
http://discover.yahoo.com/we...

Ara.T.Howard

6/10/2005 6:30:00 PM

netghost

6/14/2005 5:10:00 PM

I was thinking perhaps you can define your duck types, ie:
READABLE = [:open, :read]
SORTABLE = ['<=>'.to_sym]

Then extend Object a little:
class Object
def implements?(symbols)
symbols.all?{|s| respond_to? s}
end
end

It makes your types easily documented, and it's trivial to test if
something implements the needed functionality.
"hello".implements? SORTABLE
=> true
"hello".implements? READABLE
=> false

I'm not really a big fan of this style, but it might be handy to
someone ;)
.adam sanderson

Eric Mahurin wrote:
> I've seen many posts on what duck-typing is, that Ruby doesn't
> need static typing, that duck-typing results in easy to read
> code, etc (and others that want static typing). What I haven't
> seen much of is what advantage duck-typing gives to a method
> over conventional polymorphism. This is a follow on of my
> previous thread "making a duck". I would like to get on my
> soapbox and talk about it a little...
>
> With the polymorphism of other languages, class hierarchy is
> very important. When you specify an argument can take a
> certain class, you are saying that it can also take anything
> derived from it (or implementing the same interface if the
> language has that concept).
>
> With duck-typing, class hierarchy and class names are not
> important. Every argument that is duck-typed (built-in methods
> unfortunately usually aren't) effectively has its own "type".
> The "type" of an argument is defined by what methods it needs
> to respond to and any "type" requirements of those methods
> arguments or return values. If an argument has no method
> requirements, then that argument could be anything. With an
> argument needs to respond to just one method, you can think
> about making an object on-the-fly that meets that one
> requirement. That one method could easily be made from a
> method of another object - including Proc#call (arbitrary
> code). With an argument that needs to respond to more methods,
> you can still do the same (mapping multiple methods), but at a
> certain point it may become too cumbersome.
>
> As an example, suppose you have 2 methods in an object that
> take String-like things. With conventional polymorphism, you
> might abstract this up to anything indexable to encompass
> String and Array. With duck typing, you don't need to do
> anything explicit - just continue thinking of it like a String
> when coding the methods. Let's say one of the methods reads
> from its "String" argument using only the [] method. You could
> easily use a String, Array, Hash, or more powerfully a Proc.
> The second appends to its "String" argument using the <<
> method. Here you could easily use a String or Array. In both
> of these cases, you could grab any method of any object and map
> it to new object (and name the method appropriately). Of
> course the most flexible would be mapping a Proc#call - do
> whatever you want in that Proc.
>
> To get maximum benefit from duck-typing, several things will
> help out:
>
> * For every duck-typed argument, document what the duck-type is
> - what methods it needs to respond to and what the duck-type
> requirements are on those method arguments and return values.
> To help out with this it would be nice if we had something in
> rdoc for this - but I don't know what.
>
> * A convenient way to create objects on-the-fly for duck-typed
> arguments. Some implementations were given in the thread
> "making a duck".
>
> * Don't overload your methods. As soon as you overload a
> method to allow multiple "types" for an argument (and do
> different things based on the "type"), you are not doing strict
> duck-typing. At a minimum when you overload, you have to ask
> whether an object responds to a certain method to determine
> what to do. Doing this can limit what you can pass in due to
> ambiguities as to what the "type" is. If you make a method
> that can take a flying-thing, a swimming-thing, or a
> walking-thing, what should this method do when it receives a
> duck - because a duck can fly, swim, and walk?
>
> * The fewer methods that a duck-typed argument responds to the
> more flexibility you have in what you can pass to to it. Many
> arguments may just require one method of the argument which is
> ideal (next to zero methods of course). One method allows easy
> on-the-fly object creation as described above.
>
> * Use duck-typing everywhere!
>
>
>
> __________________________________
> Discover Yahoo!
> Have fun online with music videos, cool games, IM and more. Check it out!
> http://discover.yahoo.com/o...

comp.lang.ruby

duck-typing allows deeper polymorphism

Eric Mahurin

Robert Klemme

Ara.T.Howard

Eric Mahurin

Ara.T.Howard

Eric Mahurin

Ara.T.Howard

netghost

x Login to ForumsZone