From: Daniel Schierbeck <daniel.schierbeck@...>
Date: 2006-05-28T22:31:15+09:00
Subject: Re: Crazy thought -- Rubyish type conversion?

Florian Gro� wrote:
> ... ruby-contract uses the same adaption routes that Ruby 
> uses:
> 
>>   # Built-in adaption routes that Ruby already uses in its C code.
>>   adaption :to => Symbol,  :via => :to_sym
>>   adaption :to => String,  :via => :to_str
>>   adaption :to => Array,   :via => :to_ary
>>   adaption :to => Integer, :via => :to_int
> 
> So if it expects a Symbol anywhere it will accept a Symbol or any object 
> that has to_sym() and so on. In theory you could also add non-standard 
> adaption routes (like String => StringIO), but when you add more and 
> more of them you also add more and more sources of hard to detect bugs 
> to your application.

That's exactly what I think is the problem; you have to tell Ruby how to 
convert an object to another type anyway, so why not just use the 
established convention? Besides, I don't think it should be mandatory 
for all #to_* methods to return an * object -- I think it would be 
completely okay if #to_a returned an object that responded to all 
messages that an Array object would, in the same manner (e.g. #each 
yielded a single object.)


>>   def foo(str bar, int baz, sym bur); end
> The downside of that is that you can't anymore use any expression. With 
> eh <> syntax you can also do this:
> 
> def foo(<type_for(:foo, 1)> bar)
> def foo(<foo bar> qux)

That's true -- maybe allow both? When the delimiters are used, the 
content within is evaluated, and the returned symbol/class will be used. 
If we decide to use symbols (given that this actually gets 
implemented...) the return value should just respond to #to_sym.

   def foo(str bar, <"i" + "nt"> baz); end


Daniel