Robert Klemme
1/14/2005 12:06:00 PM
"David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.61.0501140338360.14852@wobblini...
> 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).
In fact the first character that came to mind was '#'. The char to use
here is not important to me. Here are some alternatives:
def silly_example(str.to_str, count.to_int)
def silly_example(str#to_str, count#to_int)
def silly_example(str:to_str, count:to_int)
def silly_example(str::to_str, count::to_int)
> 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.
Well, of course. But in those cases you would not use that notation. You
would simply declare the parameter as you do now and write a comment that
this parameter must respond to #times.
Btw, did you purposely just return an int from your definition of times?
I mean, no block is invoked from that method.
> (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.)
It's just another (supposedly shorter) form to write a common idiom. If
the writer of silly_example decides to do more complex treatment, he can
still do that. We don't loose anything. Note, that the creator of your
obj.times() would be similarly surprised if the implementor of
silly_example had choosen to do it exactly like I presented in the first
example.
I'm not sure whether I missed your point altogether. Could you please
elaborate? Thanks!
Kind regards
robert