Matthias Becker wrote:
> 
> MULTImethod. This means that you have methods whith is bound to multiple objects
> instead of only one. In my example I used it on only one object, so the name
> multimethod is very confusing.
> 
> Have you read my proposal?
> 
> // this is a fallback function bool intersect(Shape foo, Shape bar) {...}
> 
> // Intersection of Triangle and Square
> bool intersect(Shape @ Triangle foo, Shape @ Square bar) {...}
> 
> // Intersection of Square and Triangle
> bool intersect(Shape @ Square foo, Shape @ Triangle bar) {...}
> 
> // Intersection of two Squares
> bool intersect(Shape @ Square foo, Shape @ Square bar) {...}
> 
> You have one compiletimetype (here Shape) and one runtimetype (Here Triangle and
> Square).

Good proposal.  This may need to wait for better RTTI but it has the best syntax I've seen.  And oddly, a very similar proposal popped up today on comp.std.c++:

http://groups.google.com/groups?selm=194c1211.0407220349.3bededd3%40posting.google.com&output=gplain


Sean

>Good proposal.  This may need to wait for better RTTI but it has the best syntax I've seen.

Thanks.

>And oddly, a very similar proposal popped up today on comp.std.c++:
>
>http://groups.google.com/groups?selm=194c1211.0407220349.3bededd3%40posting.google.com&output=gplain
>
Yes, that's mine, too.

In article <cdpp68$1a61$1@digitaldaemon.com>, Sean Kelly <sean@f4.ca> wrote:

> Matthias Becker wrote:
> > 
> > MULTImethod. This means that you have methods whith is bound to multiple
> > objects
> > instead of only one. In my example I used it on only one object, so the
> > name
> > multimethod is very confusing.
> > 
> > Have you read my proposal?
> > 
> > // this is a fallback function bool intersect(Shape foo, Shape bar) {...}
> > 
> > // Intersection of Triangle and Square
> > bool intersect(Shape @ Triangle foo, Shape @ Square bar)
> > {...}
> > 
> > // Intersection of Square and Triangle
> > bool intersect(Shape @ Square foo, Shape @ Triangle bar)
> > {...}
> > 
> > // Intersection of two Squares
> > bool intersect(Shape @ Square foo, Shape @ Square bar)
> > {...}
> > 
> > You have one compiletimetype (here Shape) and one runtimetype (Here
> > Triangle and
> > Square).
> 
> Good proposal.  This may need to wait for better RTTI but it has the best syntax I've seen.  And oddly, a very similar proposal popped up today on comp.std.c++:
> 
> http://groups.google.com/groups?selm=194c1211.0407220349.3bededd3%40posting.go ogle.com&output=gplain
> 
> 
> Sean

I'm a little confused:

Is this different from function overloading in C?  If not, can't the compile time type be deduced from the child class?  As in, why do I need Shape @ Triangle.   Triangle seems to imply Shape to me.

On the other hand, is this trying to allow you to bind one function to several child types of a class, without accepting them all?  That would be something interesting, although I've never ran into a need for such a feature.

In article <schancel-C035F9.10362623072004@digitalmars.com>, Sha Chancellor says...
>
>I'm a little confused:
>
>Is this different from function overloading in C?  If not, can't the compile time type be deduced from the child class?  As in, why do I need Shape @ Triangle.   Triangle seems to imply Shape to me.

The examples were a little bit simplistic.  Assume I have a factory class that returns different objects based on user input:

class Base {}
class Derived1 : Base {}
class Derived2 : Bse {}

void multimethod( Base b ) {}
void multimethod( Derived1 b ) {}
void multimethod( Derived2 b ) {}

Base build( char[] type ) {
if( type == "Derived1" ) return new Derived1();
if( type == "Derived2" ) return new Derived2();
}

Base b = build( "Derived1" );

multimethod( b );

In D and C++ land, multimethod(base) will be called because that is the type of the variable b.  The compiler doesn't try and determine the type of the underlying instance.

I saw a good example of multimethods I think on Gamasutra.Com where the programmer had optimized collision detection functions for different pairs of shapes.  Because the shapes were all created dynamically at runtime it wasn't possible to rely on standard overload resolution to find the right function. And if all else fails there's always multimethod(base) to fall back on.  This type of thing can be accomplished manually but the implementations tend to be complex and brittle.  Having language support makes life much easier in both respects.


Sean

In article <cdrjj5$28sq$1@digitaldaemon.com>, Sean Kelly <sean@f4.ca> wrote:

> In article <schancel-C035F9.10362623072004@digitalmars.com>, Sha Chancellor says...
> >
> >I'm a little confused:
> >
> >Is this different from function overloading in C?  If not, can't the compile time type be deduced from the child class?  As in, why do I need Shape @ Triangle.   Triangle seems to imply Shape to me.
> 
> The examples were a little bit simplistic.  Assume I have a factory class
> that
> returns different objects based on user input:
> 
> class Base {}
> class Derived1 : Base {}
> class Derived2 : Bse {}
> 
> void multimethod( Base b ) {}
> void multimethod( Derived1 b ) {}
> void multimethod( Derived2 b ) {}
> 
> Base build( char[] type ) {
> if( type == "Derived1" ) return new Derived1();
> if( type == "Derived2" ) return new Derived2();
> }
> 
> Base b = build( "Derived1" );
> 
> multimethod( b );
> 
> In D and C++ land, multimethod(base) will be called because that is the type
> of
> the variable b.  The compiler doesn't try and determine the type of the
> underlying instance.
> 
> I saw a good example of multimethods I think on Gamasutra.Com where the programmer had optimized collision detection functions for different pairs of shapes.  Because the shapes were all created dynamically at runtime it wasn't possible to rely on standard overload resolution to find the right function. And if all else fails there's always multimethod(base) to fall back on.  This type of thing can be accomplished manually but the implementations tend to be complex and brittle.  Having language support makes life much easier in both respects.
> 
> 
> Sean

Rather than adding syntax, should the compiler just "take care of it"? Is there a reason why it can't, or is adding syntax just easier?

In article <schancel-C9539F.11483623072004@digitalmars.com>, Sha Chancellor says...
>
>Rather than adding syntax, should the compiler just "take care of it"? Is there a reason why it can't, or is adding syntax just easier?

It's mostly a matter of efficiency.  Normal overload resolution is handled at compile-time, while multimethod determination is handled at run-time.  If I know that only 2% of the functions I call are for dynamic objects I don't necessarily want to pay the performance cost of having all function calls resolved at run-time.  This is a side-effect of D being a weird mutant conglomeration of a few different programming styles, much like C++.  For a purely dynamic language you might want to look into Smalltalk.


Sean

In article <cdroqu$2fnt$1@digitaldaemon.com>, Sean Kelly <sean@f4.ca> wrote:

> In article <schancel-C9539F.11483623072004@digitalmars.com>, Sha Chancellor says...
> >
> >Rather than adding syntax, should the compiler just "take care of it"? Is there a reason why it can't, or is adding syntax just easier?
> 
> It's mostly a matter of efficiency.  Normal overload resolution is handled at
> compile-time, while multimethod determination is handled at run-time.  If I
> know
> that only 2% of the functions I call are for dynamic objects I don't
> necessarily
> want to pay the performance cost of having all function calls resolved at
> run-time.  This is a side-effect of D being a weird mutant conglomeration of
> a
> few different programming styles, much like C++.  For a purely dynamic
> language
> you might want to look into Smalltalk.
> 
> 
> Sean

I wasn't implying that it should be purely dynamic, I seriously dislike Obj-C and similar languages.   I was implying that the compiler might be able to make the determination based on existing information rather than having to be explicitly told.   Although I can imagine adding syntax makes it easier.

In article <schancel-FF3823.14215323072004@digitalmars.com>, Sha Chancellor says...
>
>I wasn't implying that it should be purely dynamic, I seriously dislike Obj-C and similar languages.   I was implying that the compiler might be able to make the determination based on existing information rather than having to be explicitly told.   Although I can imagine adding syntax makes it easier.

If you can suggest a method then by all means do so.  It might not be too hard to do in C++ -- dynamically bind for data allocated on the heap and statically bind otherwise -- but in D there isn't such a clear distinction.  The only other method I can think of would be to either do something special in the function declaration or define a new statement wrapper:

class A {}
class B : A {}

void func( A a ) {}
void func( B b ) {}

A a = new B();
func( a ); // calls func(A)
dynamic
{
func( a ); // calls func(B) if it exists, otherwise func(A)
}

Sean

> Since D is not going to have implicit instantiation, I suggest that we
*must*
> have the autotype keyword, which will be akin to the semantics proposed
for auto
> in C++ 0.x. That is to say, the type is deduced, at compile time - it's no variant type! - from the initialising expression, so:

While searching for threads about implicit template instantiation I tripped over this: "Since D is not going to have implicit instantiation". Is that "not" as in "not ever" or as in "not in a long time"?

-- Bent Rasmussen