Chris Dutton <[EMAIL PROTECTED]> writes:
> On Sunday, March 16, 2003, at 05:09 PM, David Storrs wrote:
>
> > ==QUESTION
> > - Page 8 says "In some languages, all methods are multimethods." I
> > believe that Java is one of these. Is that right and what are some
> > others? (This is really just curiousity.)
> > ==/
>
> Doesn't C++ work this way? Also I believe Pike allows overloading of
> methods by default.
While this isn't really perl6 related it gives me a good opportunity
to say why i WANT multimethod dispatch (and not just method
overloading (or overridding or whatever it's called)):
Let's say we have three classes:
Message
BroadcastMessage
MulticastMessage
Message is an abstract base class (or an interface) and
BroadcastMessage and MulticastMessage are conrete (instantiable)
classes which inherit only from Message.
Assuming we have a third class named MessageHandler with two methods:
method send(BroadcastMessage) { ... }
method send(MulticastMessage) { ... }
(one method specialized for arguments of the BroadcastMessage class
and one for arguments of the MulticastMessage class.)
The problem arises when we have some code which wants to use
MessageHandler's send method without caring about the type of Message:
example, suppose we have the method foo:
method foo(Message a_message, MessageHandler a_message_handler) {
...
a_message_handler.send(a_message);
...
}
Even though Message is an abstract class, and we've defined a send
method for both BroadcastMessage and MulticastMessage the call to send
with a Message argument is a compile time error becuase there is no
send method declared to tkae a Message object as an argument. This, i
hope, also shows the difference between multi-method and single-method
dispatch: _when_ the selection of which method to call happens, with
single-method we look at the args at compile time and the object at
run time, with multi-method we consider everything at run time.
While there are work-arounds (like making send a method of the Message
class) these just move the problem around until our particular app
doesn't mind, they do not _solve_ the problem.
It may just be me, but this has annoyed me more than once in my life
with Java.
> ==QUESTION
> - Also on page 9, concerning macros:
>
> "...while a macro's name may be installed in either a package
> or a lexical scope, its syntactic effect can only be lexical,
> from the point of declaration (or importation) to the end of
> the current lexical scope."
>
> Does that mean that I cannot define a bunch of commonly-used macros
> in a single file and then use them in different files?
> ==/
note the bit about "(or importation)". Just import the commonly-used
macros in every file you want, they'll be visibile from the line that
imports them until the end of the file (or the end of the current
block).
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
