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


"Mark Hubbart" <discordantus@gmail.com> schrieb im Newsbeitrag 
news:de63abca0501141100154206a8@mail.gmail.com...
> On Fri, 14 Jan 2005 19:16:12 +0900, Robert Klemme <bob.news@gmx.net> 
> wrote:
>
>> 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
>>
>> Basically this is just a way to save typing.  Error reporting will be the
>> same.  RDoc could evaluate this info and generate comments for this
>> automagically.
>
> I could count on one hand the number of times I've converted arguments
> at the top of the method. In those times, I consider it a bit of a
> breakdown of duck-typing, not an extension of it.
>
> Also, I agree with David about use of dot notation for this. This is,
> in fact the reverse behavior from the usual dot notation; instead of
> the expression returning the result of sending the message to the
> object referenced by the variable, it references the variable to the
> result of sending the message to the object.
>
> However, I'm sure there are other alternate syntaxes that will work.
> And, if you instead simply check that the passed object responds to
> the selected message, that would be, imvho, an extension of
> duck-typing....
>
>  def foo( str{to_str}, count{times} )
>    s = ""
>    count.times { s << str }
>    s
>  end

The syntax is not the problem.  In fact I provided some alternatives and I 
like your version, too.

> If foo is called with a str that doesn't respond_to?(to_str), there
> should be an error raised. Perhaps a NoMethodError, or maybe a
> TypeError, or maybe something new that means both.

NoMethod error - same as in my first example (the way one would do it 
today).

> I'm fond of doing things like this, especially for testing, and
> sometimes for working with stuff in irb:
>
>  num, str = Object.new, Object.new
>
>  def num.times(&block) 23.times &block end
>  def str.to_str() "%02i_" % rand(99) end
>
>  foo num, str  #==> "74_26_94_..."
>
> I do this to make sure I'm allowing for maximum flexibility, or when
> working with other's code, to find out what the actual requirements
> are :)

Well, then you'll learn that your instance must implement to_int.  Same as 
if someone had coded that directly in the method.  I don't see this as an 
argument against my suggested shortcut syntax, because that mainly affects 
the *writer* of a method - not the *caller*.

> There are a couple of problems still: First, an object might still be
> able to respond to a message, using method_missing, but #respond_to?
> won't show it.

You introduced the #respond_to? - my suggestion was to simply invoke it and 
see what happens (duck typing).

> Second, I'm not sure about the syntax. It would work
> (it currently give a parse error), but I think something better and
> more self-explanatory could be found.

Sure.  I'm very open here.  I think the selection of "." as separator was 
not good.  We can change that any time.  But the real issue for me is, does 
this make sense independend of syntax?

Kind regards

    robert