[ruby-talk:17880] Re: Overloaded methods

"HarryO" <[e-mail]> wrote in message
news:[e-mail]...
> >  Java (TM), but I don't want to have problem with Sun's lawyers if I
> >  forget
> > the copyright :-))))
>
> Fair enough.  I have nothing they could weasle out of me :-).
>
> > H> you just not like writing that word?  If the latter, what's a
> > "parasitic" H> method?  I've not seen that term used before.
> >
> >   http://www.cs.uwm.edu/~boyland/papers/parasitic-methods.html

I'd not heard that term before either. It is a rather weird although
descriptive term for what is being done.

The more "correct/popular" term in OO literature is "around" methods (from
CLOS [lisp]); or its equivalent term "outer/inner" methods from (Simula,
etc). The
general concept is what is called a "wrapper" method. This is one of the
popularly used techniques in aspect oriented programming facilities.

In Smalltalk (and in particular my work in QKS Smalltalk and SmallScript)
the general pattern is called a "wrapper" method. For specific aspect
related
support they are called "around" methods are part of the MOP services that
also provide "before" and "after" methods which would be synonomous with the
pre/post condition ideas as expressed in Eiffel's design by contract
architecture.

Noting that Ruby does not require static type declarations and is thereby a
dynamically typed language, following Java designs is relatively pointless
and will lead you down the wrong implementation path.

You might want to check out the definitive work on this topic from the early
90's. The Common Lisp Object System book -- "The Art of the Metaobject
Protocol" by Gregor Kiczales, et al. It is a straightforward read and will
expose you to both the ideas and their pragmatic rationale.

>
> I obviously don't really understand what the different is between simple
> overloaded methods and the concept of multimethods.

There isn't any difference. This is just a terminology issue which depends
on what "school" of thought the idea was generated from. The more general
term "multimethod" predates the narrower term "overloading".

The "overloading" term takes on quasi special meaning in the context of
languages that have intrinsic "operators" but which were extended to give
those operators user-definable "method" like behavior [witness C++].

In languages like Smalltalk and Lisp, what is commonly thought of as
operators have always user definable methods and so the distinction was
never necessary/meaningful.

In my work on SmallScript/QKS-Smalltalk and its AOS Platform execution
engine (as well as .NET) I've implemented hi-performance multi-method
services. A Ruby implementation built on top of the underlying execution
technology I developed for both the AOS Platform and the .NET platform would
give Ruby free multi-methods.

Unfortunately it could not follow the Ruby open-source model for things.
Perhaps evolution in the Mono (Ximian) project to make a GNU.NET platform
will make this possible. But, as of now, I'm the only party that has
developed an efficient (dynamic dispatch) multi-method architecture for .NET
and it is based on a lot of years of my personal work, R&D investment, and
experience for which I intend to be compensated through licensing.

There is a rich array of things that multi-methods enable and there are many
type system related semantics that go along with such an architecture. The
most obvious (frequently cited) example is the generalization of libraries
for numerics and linear algebra. Where the classic technique (without
multi-methods) is to use double dispatch. But there are many others such as
foreign function interfaces, multi-threading safety, and a range of string
and character processing services.

Assuming the standard source base for Ruby is using Smalltalk (from which
Self was derived) style dynamic dispatch then you have the basic foundations
in the VM sources to extend it to support efficient multi-methods and
adaptive jit compilation.

--
-- Dave S. [ http://www.smallscript.net ]

> I guess I'll do a
> quick search to see if I can find some info.  Unfortunately, not being a
> member of the ACM, I couldn't download that paper.
>
> > H> This code confused me.
> >
> >  modified version of ruby
>
> Ah!