Hi --

On Fri, 14 Jan 2005, Robert Klemme wrote:

>
> Hi all,
>
> conversion of method parameters seems to be a quite common scenario,
> example:
>
> def silly_example(str, count)
>  str = str.to_str
>  count = count.to_int
>
>  s = ""
>  count.times { s << str }
>  s
> end
>
> 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
>
> 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.
>
> Of course, any method could be invoked like this, maybe even with
> parameters.  I haven't thouroughly thought about implications of that fact
> yet.
>
> Thoughs?

I personally don't like the '.' notation used for anything other than
method calls (and floats :-)  I just think it's too important and
central a notation to be borrowed for something else, even something
that is somewhat kindred to a method call (but isn't one).

There's also the question of the interaction of this with duck typing.
Of course that's always a programmer's choice, but I could imagine
cases where the caller would expect a duck-typing treatment and not
get it.  For example:

   obj = Object.new
   def obj.times; 10; end
   str = silly_example("hello", obj)

Here you have an object that responds to 'times', so it's capable of
being treated in a duck-typing way by simply being sent the message
'times' -- but if you intercept the object and do a to_int on it,
there's trouble.

(Of course you could document your method by saying that it requires
an object that responds to to_int, but that seems a bit roundabout
compared to just saying you want an object that responds to times.)


David

-- 
David A. Black
dblack / wobblini.net