duck-typing allows deeper polymorphism
Eric Mahurin
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/online.html
Robert Klemme
<snip>a lot of good stuff</snip>
> * Use duck-typing everywhere!
Well quacked! ;-)
Kind regards
robert
Ara.T.Howard
<snip good comments>
i've had many of the same thoughts and tried to address them as simply as
possible in my parseargs module
> 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.
> * 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"
> * Use duck-typing everywhere!
hear hear!
cheers.
-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple. My religion is kindness.
| --Tenzin Gyatso
===============================================================================
twi...@comcast.net
> which must respond to 'upcase', and 'downcase'. an exception is thrown if
> something that does not respond to both these methods is passed in:
> note that this could be parsed via rdoc quite easily.
Only if it's an Array literal being passed to parseargs.
Ara, I'm not trying to dismiss the effort you put into parseargs, or its usefulness in pulling off programming by contract (especially in comparison to the alternatives). Rather, I'm trying to point out that Ruby's so flexible that it makes it very difficult to do. I'm not arguing against duck typing -- enough people have done that already, plus I like it. However, I still have qualms about using Ruby in the enterprise (read: with a bunch of programmers who aren't me), and duck typing is one of the reasons why.
Once I formulate all my thoughts, I'll probably make an "Enterprise Ruby?" email or something, but for now, all you get is little nits.
Devin
Ara.T.Howard
>> 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:
> Not entirely true... The argument 'x' must also respond to whatever
> parseargs wants from it (respond_to?, I assume), whatever the 'pa.x' method
> wants from it (well, nothing, I assume), and whatever 'p' wants from it
> (to_s, I assume).
sure - everything in :ducktype=>list AND what parseargs needs - quite true.
>
>> note that this could be parsed via rdoc quite easily.
> Only if it's an Array literal being passed to parseargs.
huh?
> Ara, I'm not trying to dismiss the effort you put into parseargs, or its
> usefulness in pulling off programming by contract (especially in comparison
> to the alternatives).
oh but you should! ;-) it's marked 'experimental' for at least a couple of
reasons and is just an idea i'm throwing out there to see what comes back.
for the record: by no means am i suggesting it's a completely baked idea.
we're all friends here so i assume people will offer up any criticisms come to
mind.
> Rather, I'm trying to point out that Ruby's so flexible that it makes it
> very difficult to do. I'm not arguing against duck typing -- enough people
> have done that already, plus I like it. However, I still have qualms about
> using Ruby in the enterprise (read: with a bunch of programmers who aren't
> me), and duck typing is one of the reasons why.
i can see that.
twi...@comcast.net
> > parseargs wants from it (respond_to?, I assume), whatever the 'pa.x' method
> > wants from it (well, nothing, I assume), and whatever 'p' wants from it
> > (to_s, I assume).
>
> sure - everything in :ducktype=>list AND what parseargs needs - quite true.
> >> note that this could be parsed via rdoc quite easily.
> > Only if it's an Array literal being passed to parseargs.
> huh?
def method(*argv)
pa = parseargs(argv){
arg :x, :ducktype => File.new('methods.txt').readlines.each { |line|
line.chomp
}
}
p pa.x.upcase.downcase
end
> we're all friends here so i assume people will offer up any criticisms come to
> mind.
Ok. Thanks!
Devin
Eric Mahurin
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.
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.
Ara.T.Howard
> I don't really like this because:
>
> a. if you put this all over the place, it will significantly
> degrade the code readability
i strongly disagree here. in the case of short examples it is roughly
equivalent
def method argv
pa = parseargs(argv){
required_argument 'a'
optional_argument 'b'
}
end
four lines
def method a, b
@a = a
@b = b
end
two lines
in the real world, in case where you might actually use parseages, it will
shine
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
four lines
now, if you write some loop that accepts all those kewords and loads them into
a hash, openstruct, or something - and does not allow any other keywords,
raising an ArgumentError if they are passed in, and then you duplicate this in
all the methods that have that kind of logic, your code will be at least 10
time more verbose and obfusicated.
essentially your comment is like saying
help = (ARGV.include? '-h' or ARGV.include? '--help')
is better/more readable than using optparse or getoplong. true if that's all
you are doing (for instance in an example) - otherwise severely false.
another example
class CascadingStyleSheet
class Element
FontProperties = %w(
font-family
font-style
font-variant
font-weight
font-size
font
)
ColorAndBackgroundProperties = %w(
color
background-color
background-image
background-repeat
...
...
)
TextProperties = %w(
...
...
)
BoxProperties = %w(
...
...
)
ClassificationProperties = %w(
...
...
)
CSSProperties = FontProperties + ColorAndBackgroundProperties +
TextProperties + BoxProperties + ClassificationProperties
attr 'selector'
CSSProperties.each{|prop| attr prop}
def initialize argv
pa = parseargs(argv) {
required_argument 'selector'
keywords CSSProperties
}
self.selector = pa.selector
CSSProperties.each{|prop| send prop, pa.prop}
end
def font_configure argv
pa = parseargs(argv) {
keywords FontProperties
}
...
end
def box_configure
pa = parseargs(argv) {
keywords FontProperties
}
...
end
end
end
it's this kind of code that spirals out of control with rampant DRY violations
unless parseargs or a roll-your-own type argv parsing scheme is devised.
> 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.
> 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.
again - it's __experimental__. these kinds of comments are great and
precisely what this group is best at.
> d. this only starts to capture the true duck-type.
absolutely true. remember - it's an arg parsing module not a duck typing
toolset.
> 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.
absolutely. there are several attempts on the RAA.
> If you are able to implement that, then you really are going to make the
> first problem even worse - code clutter.
which is is why i chose to implement the simplest possible thing that could
work and which covers the most common usage. at the very least it's something
people might be able to build upon.
> 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.
three days - banking transactions - remote method invocations... there are
tons of scenarios where you need to either know your object can do such and
such or try to make it if does not because each attempt is expensive in terms
of disk, cpu, or network. it's luxurious to be able to write code that can
just crash or be run again - but it's not always possible.
>> 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?
Ara.T.Howard
ah. true true. at least the docs could show the rhs of the '=>' sign which
would, in 99% of cases, but quite informative.
Eric Mahurin
> 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/weekend.html
Ara.T.Howard
> --- "Ara.T.Howard" <Ara.T....@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.
well, me too for the most part and i rarely use the the :type/:ducktype
options myself - but i do use them at times...
> 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).
exactly. i end up with stuff like that alot around here...
> 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.
this seems more or less correct... i haven't considered it quite that way.
> 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.
at first glance this sounds o.k. - but i think i would lead to many sublte
errors like we see in perl. that may sound like i'm contra-dicting myself;
after all, i use duck typing all the time. but there is a big difference
between user written code and language level libs : namely that i know with
great certainty the environment much of my code runs in. for instance i might
know that only i will ever use it ;-) that's not the case with built-ins
though and i, for one, am glad '0' will never act like 0. i conceed that
there are some cases where it would might make sense though - it should just
be considered very very carefully for core code.
netg...@gmail.com
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