Hi --

On Wed, 27 Jun 2007, Trans wrote:

>
>
> On Jun 23, 9:21 pm, "Gregory Brown" <gregory.t.br... / gmail.com> wrote:
>> On 6/23/07, Trans <transf... / gmail.com> wrote:
>>
>>
>>
>>
>>
>>> On Jun 23, 6:09 pm, darren kirby <bulli... / badcomputer.org> wrote:
>>>> *Sigh*, I mean:
>>
>>>>   # Writes embedded images to a file
>>>>   #
>>>>   # :call-seq:
>>>>   #   write_picture()                       -> nil
>>>>   #   write_picture(:outfile=>"str")        -> nil
>>>>   #   write_picture(:n=>int)                 -> nil
>>>>   #   write_picture(:outfile=>"str", :n=>int) -> nil
>>
>>>> -d
>>
>>> Bingo.
>>
>>> But hey, as Resident Dreamer, I can't help but wonder how cool it
>>> might be to have highly descriptive and auto-flexible arguments:
>>
>>>   def write_picture(n <= Integer, outfile <= String)
>>>     ...
>>>   end
>>
>>>   write_picture("front cover", 1)
>>>   write_picture(1, "front cover")
>>
>>> Sacrifice a little duck-typiness for some arg-flippiness :)
>>
>> Yuck.
>
> Is the "formalist" in you disturbed by this?
>
> I think too many programmers feel that way too. See, I wonder when we
> ever are going to get past conforming to the requirements of our
> computer systems, and start having them conform to ours.

Nothing that abstract or sweeping is at stake.  (I don't think
Rubyists who dislike the thought of automatic class-checking are,
overall, more subservient to their computers than those who don't :-)
It's just that constraining Ruby method arguments to be of certain
classes is both unnecessarily limiting and not as much of a guarantor
of behavior as people sometimes think (since the objects don't "know"
that they're supposed to ignore the side of themselves that allows for
dynamic typing).  In the case of checking class membership in order to
allow arbitrary argument order, you'd also run aground on the fact
that a method might take more than one string, or whatever.


David

-- 
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)