Re: Nice multiple dispatch details

Thanks Daniel for the clarification,

after playing a little with the nice compiler I realized that the 
programmer is actually in control of which method bodies belong to a 
method group. In this example:

	class Vehicle;
	class Car extends Vehicle;
	class Driver;

	String toString(Vehicle a1) = (...);
	String toString(Car a1) = (...);

the two toString() methods are not in the same method group (even 
though they have the same name and number of arguments, and the 
argument types are relate by inheritance) because they have 
different declarations.

In contrast:
	String toString(Vehicle a1) = (...);
	toString(Car a1) = (...);

are in the same method group.

Conversely,
	String toString(Vehicle a1) = (...);
	toString(Car a1) = (...);
	toString(Driver a1) = (...);

are not all 3 in the same method group (only the first 2).

cheers,
Radu


On Wed, 13 Feb 2008, Daniel Bonniot wrote:
> Hi,
>
> On Feb 7, 2008 8:09 AM,  <[email protected]> wrote:
> > Hi,
> >
> > I have a few questions regarding the multiple dispatch mechanism
> > in Nice and how it compares to other languages (CLOS, Dylan,
> > Cecil etc.)
> >
> > When calling a method, Nice, like other multiple dispatch
> > languages, has to chose the most appropriate method body from a
> > set of available definitions (based on the dynamic type of the
> > supplied arguments, of course).
> >
> > What are the criteria of grouping method definitions into a
> > "dispatch set":
> > - the method's name (I assume)
>
> yes
>
> > - the package where the method is defined?
>
> they don't have to be in the same package, as long as all packages
> are visible by being imported
>
> > - the number of arguments?
>
> yes
>
> > - static types of arguments?
>
> yes. Precisely, a method will override all other methods when both
> would be applicable for some same set of arguments, and the
> overriding methods has more specific types than the overriden one.
>
> > In other words....
> >
> > * Example1:
> >         package Car;
> >         foo(Car a1, Motorcycle a2)
> >         package Motorcycle;
> >         foo(Motorcycle a1, Truck a2)
> > ...will these methods be the same dispatch set?
>
> No, given I assume something cannot be both a motorcycle and a
> truck.
>
> But if there was also a foo(Vehicule, Vehicule), then that one
> would be overridden by both of yours.
>
> > * Example2:
> >         foo(Car a1, Motorcycle a2)
> >         foo(Car a1, Motorcycle a2, Truck a3)
> > ...will these methods be in the same dispatch set?
>
> No.
>
> > * Example3:
> >         abstract class Vehicle;
> >         class Car extends Vehicle;
> >         abstract class Person;
> >         class Driver extends Person;
> >
> >         toString(Car a1) = (...);
> >         toString(Driver a1) = (...);
> >
> >         void main(String[] args) {
> >                 let d = new Driver();
> >                 toString(d);
> >         }
> > ... will the 2 methods be in the same dispatch set?
>
> Yes.
>
> > I.e. when calling
> > toString() with a Driver as an argument, will both method
> > definitions be considered at runtime? Or is the compiler able to
> > disambiguate these two, eliminating the need for dynamic
> > dispatch (in this particular case)?
>
> I believe the compiler will avoid the dynamic dispatch in this
> particular case, but that's an implementation detail (an
> optimization).
>
> You are welcome to write such programs yourself to check the
> behaviour of the compiler.
>
> Cheers,
>
> Daniel
>
> ------------------------------------------------------------------
>------- This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Nice-info mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nice-info

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/