Re: duck-typing allows deeper polymorphism

--- "Ara.T.Howard" <[e-mail]> 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/weekend.html