http://nice.sourceforge.net/visitor.html

Good advice from the Nice language, http://nice.sourceforge.net/index.html

Mark

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:b314qm$sns$1@digitaldaemon.com...
>
> http://nice.sourceforge.net/visitor.html
>
> Good advice from the Nice language, http://nice.sourceforge.net/index.html

Do all the incarnations of a particular multimethod function all need to be done at once (like methods in a class, or members of a template)?

>Do all the incarnations of a particular multimethod function all need to be done at once (like methods in a class, or members of a template)?

What does that mean, 'done at once'?

Mark

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:b4b6sq$2fpg$1@digitaldaemon.com...
> >Do all the incarnations of a particular multimethod function all need to
be
> >done at once (like methods in a class, or members of a template)?
> What does that mean, 'done at once'?

All be in the same scope, just like overloaded functions must be.

Walter says...
>
>> >Do all the incarnations of a particular multimethod function all need to be done at once (like methods in a class, or members of a template)?
>>
>> What does that mean, 'done at once'?
>
>All be in the same scope, just like overloaded functions must be.
>

Off the top of my head, no.  The (first-class) generic function has some scope but the multimethods it 'owns' may live anywhere.  It's just a question of how the call is dispatched.  That determination is made by the ("multi") argument specializers and the design of the dispatch rules in the language.  Those rules could be as wild as your imagination.

Of course a major benefit of multimethods is that they can (should?) live outside class scope.  This technique solves exactly Bill's problem of how to 'add members to multiple existing classes.'  In terms of scope they might, e.g., live in several different modules, even if none of them are class members per se.

Always subject to correction,
Mark


Possibly helpful links, and a quote:

http://www.openbg.net/sto/newsread.php?grp=comp.lang.clos&msg=msg00246.html http://www.openbg.net/sto/newsread.php?grp=comp.lang.clos&msg=msg00244.html http://www.op59.net/cmm/cmm-0.15/users.html http://www.functionalobjects.com/resources/white-paper.phtml http://monday.sourceforge.net/wiki/index.php/MultiMethods http://www.cyberdyne-object-sys.com/oofaq2/body/basics.htm#S1.19 http://www.psg.com/~dlamkins/sl/chapter14.html http://www.cis.ohio-state.edu/~gb/Brew/Publications/HalfNHalf.pdf http://www.research.ibm.com/people/d/dgrove/papers/phd-thesis.pdf http://www.cs.washington.edu/homes/todd/research/ecoop99.ps

'In object-oriented languages with multimethods...the appropriate method to invoke for a message send can depend on the run-time class of any subset of the message arguments, rather than a distinguished receiver argument. Multimethods unify the otherwise distinct concepts of functions, methods, and static overloading, leading to a potentially simpler language. They also support safe covariant overriding in the face of subtype polymorphism, providing a natural solution to the "binary method" problem and a simple implementation of the "strategy" design pattern.  Finally, multimethods allow clients to add new operations that dynamically dispatch on existing classes, supporting a form of what we call "open objects" ... that enables easy programming of the "visitor" design pattern and is a key element of aspect-oriented programming. Open objects also relieve the tension observed by others between ease of adding operations to existing classes and ease of adding subclasses.'

Correct me if I'm wrong, but aren't multimethod dispatch methods always some sort of runtime search at the time of the method call?  Even if the search is optimized by the compiler (to a binary search or somesuch), doesn't this implementational requirement cross the line in terms of performance?

Dan

Dan Liebgold wrote:
> Correct me if I'm wrong, but aren't multimethod dispatch methods always some
> sort of runtime search at the time of the method call?  Even if the search is
> optimized by the compiler (to a binary search or somesuch), doesn't this
> implementational requirement cross the line in terms of performance?
> 
> Dan

That sounds right to me.

Bill

"Dan Liebgold" <Dan_member@pathlink.com> wrote in message news:b4ip35$ao7$1@digitaldaemon.com...
> Correct me if I'm wrong, but aren't multimethod dispatch methods always
some
> sort of runtime search at the time of the method call?

Yes.

> Even if the search is
> optimized by the compiler (to a binary search or somesuch), doesn't this
> implementational requirement cross the line in terms of performance?

It still should work out better than a sequence of if(dynamic_cast<...

In article <b4jrb6$cvc$2@digitaldaemon.com>, Walter says...
>>
>> Even if the search is
>> optimized by the compiler (to a binary search or somesuch), doesn't this
>> implementational requirement cross the line in terms of performance?
>
>It still should work out better than a sequence of if(dynamic_cast<...

Great! Walter, sounds like you're interested in implementing multimethods in D?

If you keep your minds open like this, I'm sure D will have a bright future!

BTW, the following is what I wish to see before version 1.0:

-- Object persistence: save/load objects to/from memory/disk/network.

-- covariant (or anchored) type not just on function return type, but also on parameters: e.g. even without template, we can still write the correct deepCopy for any object as:

like this deepCopy(like this anObj);

(for anyone who read Eiffel, you know where I come from :-).

Hey peoples,

I would like to thank Mark Evans for his numerous contributions to this mailing list.

Multi-methods are great!!

Implementation can be done in a number of ways.

O(1) complexity can be achieved by indexing types and storing an N-Dimensional lookup table of function pointers.

If the memory footprint for the N-Dimensional table gets to be too large, then you could store the function pointers in a binary tree.

If multi-methods are implemented correctly, they will enhance performance, and save a lot of coding in many instances.  Writing your own multiple-dispatch is a pain, and usually involves long switch statements (yuck)!  I know from experience.

Craig