From: Eric Mahurin <eric_mahurin@...>
Date: 2005-08-04T00:03:44+09:00
Subject: Re: [RCR] array or with non-array

--- Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

> Hi,
> 
> In message "Re: [RCR] array or with non-array"
>     on Wed, 3 Aug 2005 10:40:03 +0900, Eric Mahurin
> <eric_mahurin@yahoo.com> writes:
> 
> |Having the the method take any object that implements the
> to_s
> |is good duck typing, but then we get right back to static
> |typing as soon the the built-in methods use the result of
> to_s
> |- they require it to be a string.
> 
> I know but it is a matter of cost both efficiency and
> implementation.
> Since current "restriction" covers 99.99% usage of strings,
> it is
> kinda hard to pay cost to implement full polymorphic
> arguments like
> you mentioned.  When MetaRuby comes true, I'm not going to
> oppose,
> perhaps.

Right now, it probably covers 100%.  I think it is hard to
determine the usefulness of many features like this until it
they are implemented.

> |But, this wasn't really what my #1 above was about.  It was
> |about overloaded methods where the functionality is
> determined
> |by looking at the type of the arguments.  One example would
> be
> |String#[arg]:
> |
> |str[fixnum] => fixnum or nil
> |str[range] => new_str or nil
> |str[regexp] => new_str or nil
> |str[other_str] => new_str or nil
> |
> |All of these behave very different.  The way you figure out
> |what to do is based on type - which goes against the
> |duck-typing philosophy.  I think the only advantage of
> |combining all of these functions into one method is
> |convenience.  But, by doing so you loose the ability to
> handle
> |more general duck-typed/polymorphic arguments.
> 
> Convenience is important, sometimes more than pure duck
> typing.
> There still be a room for improvement though.

I'm more of a purist and thus prefer the purity over the
convenience.  And I know there may not be many in my camp.

As long as the built-in methods don't handle full
duck-typed/polymorphic arguments, the above overloading isn't
an issue.  In the case above, all of the object types are
exclusive.  I think cases where the object types aren't
exclusive or you have to prioritize is not a good thing.  Those
cases lead to confusion and inconsistencies.  An example would
be the overloading of Array#| you just added as a trial.  With
this, you can now OR in any single element to the array EXCEPT
when that element is an Array.  That exception case exists
because you can OR in a single element or an Array and the
Array case takes precedence.  If you look at almost any
non-trivial bug in software, it happens when?  exceptions and
end-cases.  Putting intentional exceptions in the methods only
makes the problem worse - the caller now may have to handle
that same exception/end-case.

> |I think a primary example where I would really like real
> |duck-typing in a built-in would be Regexp#match(str).  This
> |requires the arg to be a String.
> 
> Again, it's a matter of cost.  For example, full duck typing
> Regexp#match likely requires re-implementation of a regular
> expression
> matching engine in Ruby.
> 
> 							matz.

It would definitely increase the code size.  But, it shouldn't
change the run-time efficiency.  Right now Regexp#match(str)
probably looks something like this:

raise(...) if !(String===str)
# code to match against a String

This would become

if String===str
  # code to match against a String (functionally same as below)
else
  # full duck-typed code using methods of str
end


Anyways, I'm glad I brought this up so that you can at least
give it some thought...  Everybody talks about having your Ruby
code duck-typed, well why not ask the same of the built-in
methods?



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs