From: Dale Martenson Date: 2002-09-13T05:02:02+09:00 Subject: RE: not grasping the method overloading/multi-dispatch thing This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C25A97.192657E0 Content-Type: text/plain; charset="iso-8859-1" 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 :-) I'm picturing things like: > > > > > > 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 like > > > > def 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. > I see this as a big advantage to the language. 1. Overloading doesn't break a great language. It just enhances it. Ruby would still retain everything that makes it neat. 2. 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!! :-) 3. If Ruby is ever to be JIT-compiled, knowing a parameters type has advantages for performance since code can be optimized. ------_=_NextPart_001_01C25A97.192657E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: not grasping the method overloading/multi-dispatch = thing

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 :-)  I'm picturing things like:
> > >
> > >   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 like
> >
> >   def 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.
>

I see this as a big advantage to the language. =

1. Overloading doesn't break a great language. It = just enhances it. Ruby would still retain everything that makes it = neat.

2. 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!!  :-)

3. If Ruby is ever to be JIT-compiled, knowing a = parameters type has advantages for performance since code can be = optimized.

 

------_=_NextPart_001_01C25A97.192657E0--