From: Robert Klemme <bob.news@...>
Date: 2005-01-15T01:36:12+09:00
Subject: Re: Duck Typing and automated Conversions


"itsme213" <itsme213@hotmail.com> schrieb im Newsbeitrag
news:YyRFd.6210$_56.802@fe2.texas.rr.com...
> "Robert Klemme" <bob.news@gmx.net> wrote
>
> > Usually these conversions are documented as requirements for method
> > parameters.  We could make them a bit more explicit without changing
much
> > especially not the power of Duck Typing.  Here's an idea:
> >
> > def silly_example(str.to_str, count.to_int)
> >   # str and count are converted like in the example above
> >   s = ""
> >   count.times { s << str }
> >   s
> > end
>
> I like this, and believe it can be generalized to be quite broadly
useful.
>
> I believe your signature tells a caller the following:
>     silly_example takes 2 params, x and y
>         (str and count, if you prefer; but see * below)
>         x must support #to_str, y must support #to_int

Correct.

>     silly_example will use them as follows:
>         str = x.to_str
>         count = y.to_int

Correct.

>     silly_example will not have other access to x, y
>     (*: since you did: str=str.to_str; count=count.to_int)

Wrong, because to_str need not create a new instance:

>> s = "foo"
=> "foo"
>> s.id
=> 135026792
>> s.to_str.id
=> 135026792

> There are 3 main properties about this signature:
> 1. it reveals the duck-type of x, y as required methods

Yep.

> 2. it reveals how those methods of x, y are used in the body
>     str = x.to_str
>     count = y.to_int

Yep.

> 3. it saves typing: in particular, it has "no extra cost", since it
> automatically binds str and count and this does not have to be repeated
> within the body of f().

Exactly.

> What do you think about the following generalization of your idea? It
will
> be a bit of a jump, so *please* consider it carefully:
>
>     Allow a method signature to optionally indicate both
>     the duck type of a parameter (what methods it should
>     respond_to), as well as named variable bindings that
>     indicate the usage of those respond_to methods within
>     the method body.

I'll have to sleep over this.  You'll get an answer later.

Kind regards

    robert