I see this as a big advantage to the language.
-
Overloading doesn’t break a great language. It just enhances it. Ruby
would still retain everything that makes it neat. -
It allows for “cleaner” solutions where overloading is the “best” option.
It could be argued that overloading is needed to satisfy POLS. If Ruby is
truly the best OO language, how can it not have overloading!!
-
If Ruby is ever to be JIT-compiled, knowing a parameters type has
advantages for performance since code can be optimized.
···
On Thursday, September 12, 2002 8:25 AM, dblack@candle.superlink.net wrote:
On Thu, 12 Sep 2002, Pit Capitain wrote:
On 12 Sep 2002, at 21:14, dblack@candle.superlink.net wrote:
As Matz pointed out overloading would be in the spirit of Ruby
Right, but that’s the part I don’t get
def meth(Integer n, String s)
…
def meth(Float f, String s)
…and somewhere along the line I’m not clear on how that fits into the
spirit/design/philosophy of Ruby.David, as I understand it, of course you would still be able to do
def meth(f, s)
which would be equivalent to
def meth(Object f, Object s)
Only if you wanted to have a different behaviour dependend on the
types of the arguments you would do something likedef meth(Integer n, s)
def meth(Float f, s)So it really would be an addon to current Ruby, not breaking any
existing code.True, it wouldn’t break code, but it would (for me) completely change
the “feel” of Ruby. Also, I think we’d start to see very little of
this:def meth(n)
and lots and lots of this, even where it wasn’t necessary:
def meth(Integer n)
I think the availability of this kind of thing would deter many people
from exploring what is unique about Ruby.