class A {
  void foo() {}
}

class B : A {
  void foo(int i) {}
}

void main() {
  (new B).foo();
}

don't compile with the message
foo.d(10): function foo (int i) does not match argument types ()

It compiles fine if foo (int i) is moved to A.
So, if a method in a subclass has the same name as a method in the
super class, but with a different signature, the method from the
super class is lost. Since they are allowed to live together in the
same class, they should in parent and child classes.

Lars Ivar Igesund

Lars Ivar Igesund wrote:

> Since they are allowed to live together in the
> same class, they should in parent and child classes.

Not a bug. Overriding a function hides the overridden overloaded functions in the super class. Use an alias to import them.

From C:\dmd\html\d\declaration.html:

Aliases can also 'import' a set of overloaded functions, that can be
overloaded with functions in the current scope:
	class A {
	    int foo(int a) { return 1; }
	}

	class B : A {
	    int foo( int a, uint b ) { return 2; }
	}

	class C : B {
	    int foo( int a ) { return 3; }
	    alias B.foo foo;
	}

	class D : C  {
	}


	void test()
	{
	    D b = new D();
	    int i;

	    i = b.foo(1, 2u);	// calls B.foo
	    i = b.foo(1);	// calls C.foo
	}

So long!

Manfred Nowak wrote:
> Lars Ivar Igesund wrote:
> 
> 
>>Since they are allowed to live together in the
>>same class, they should in parent and child classes.
> 
> 
> Not a bug. Overriding a function hides the overridden overloaded functions
> in the super class. Use an alias to import them.
> 
> From C:\dmd\html\d\declaration.html:
> 
> Aliases can also 'import' a set of overloaded functions, that can be overloaded with functions in the current scope:
> 	class A {
> 	    int foo(int a) { return 1; }
> 	}
> 
> 	class B : A {
> 	    int foo( int a, uint b ) { return 2; }
> 	}
> 
> 	class C : B {
> 	    int foo( int a ) { return 3; }
> 	    alias B.foo foo;
> 	}
> 
> 	class D : C  {
> 	}
> 
> 
> 	void test()
> 	{
> 	    D b = new D();
> 	    int i;
> 
> 	    i = b.foo(1, 2u);	// calls B.foo
> 	    i = b.foo(1);	// calls C.foo
> 	}
> 
> So long!

I admit that I expected D to function as Java in this regard.
My opinion now is that D's spec has a bug. It should NOT be
necessary to alias the super class' foo to be able to call it.
IMO this defeats much of what makes OOP easy and elegant to use.
Walter, please do it the obvious way.

Lars Ivar Igesund

Lars Ivar Igesund wrote:

> Walter, please do it the obvious way.

Have a look at Ben's opinion on that. My opinion is, that the obvious way is already implemented.

<btr852$2d1q$1@digitaldaemon.com> == http://www.digitalmars.com/drn-bin/wwwnews?D/21549

So long!

It's implemented the C++ way because apparently that's the target audience for D (rather than Java, for example).

I find the approach totally non-intuitive, and contrary to the notion of easy-to-learn (surely alias is considered a somewhat 'advanced' topic, if not downright arcane?).

Personally, I think pandering to C++ history is the wrong approach. Walter has already sidestepped a lot of the nonsense introduced by Bjarne-The-Toker ... this is one of the last vestiges, and needs some further excising.

- Kris



"Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:c4erto$278o$1@digitaldaemon.com...
> Manfred Nowak wrote:
> > Lars Ivar Igesund wrote:
> >
> >
> >>Since they are allowed to live together in the
> >>same class, they should in parent and child classes.
> >
> >
> > Not a bug. Overriding a function hides the overridden overloaded
functions
> > in the super class. Use an alias to import them.
> >
> > From C:\dmd\html\d\declaration.html:
> >
> > Aliases can also 'import' a set of overloaded functions, that can be
> > overloaded with functions in the current scope:
> > class A {
> >     int foo(int a) { return 1; }
> > }
> >
> > class B : A {
> >     int foo( int a, uint b ) { return 2; }
> > }
> >
> > class C : B {
> >     int foo( int a ) { return 3; }
> >     alias B.foo foo;
> > }
> >
> > class D : C  {
> > }
> >
> >
> > void test()
> > {
> >     D b = new D();
> >     int i;
> >
> >     i = b.foo(1, 2u); // calls B.foo
> >     i = b.foo(1); // calls C.foo
> > }
> >
> > So long!
>
> I admit that I expected D to function as Java in this regard. My opinion now is that D's spec has a bug. It should NOT be necessary to alias the super class' foo to be able to call it. IMO this defeats much of what makes OOP easy and elegant to use. Walter, please do it the obvious way.
>
> Lars Ivar Igesund

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote:

> It's implemented the C++ way because apparently that's the target audience for D (rather than Java, for example).

Nothing wrong with that in itself, since people in general don't want massive changes that require re-thinking from the beginning. D is as good as it now because a lot of what we know from C++ still applies. I was able to get a simple game working in a day or two (yes, after the usual newbie mistakes, but once solved I was "up and running").

> I find the approach totally non-intuitive, and contrary to the notion of easy-to-learn (surely alias is considered a somewhat 'advanced' topic, if not downright arcane?).

IMO, you shouldn't be forced to use alias (or anything else) for normal code. A language should work as expected by a typical user, which is one area where C++ falls on its face, and where D can outshine it. The Java approach is more sensible and workable in the real world -- of the two, I would almost always choose Java's way over C++ (where they are comparable). I suspect that this overload behavior may already be engrained in D, however.

> Personally, I think pandering to C++ history is the wrong approach. Walter has already sidestepped a lot of the nonsense introduced by Bjarne-The-Toker ... this is one of the last vestiges, and needs some further excising.

I couldn't agree more.

-- 
dave

Lars Ivar Igesund wrote:
> I admit that I expected D to function as Java in this regard.
> My opinion now is that D's spec has a bug. It should NOT be
> necessary to alias the super class' foo to be able to call it.

Ouch, I must have missed Ben's post earlier about this.  It will make the port of SWT --> DWT a real pain in the ass.  I was also (incorrectly) assuming that you could overload away.

I'll have to agree with the rest of the thread that, even though it doesn't phase the C++ people, Java may have a more intuitive solution here.  Besides, D will not only win over a lot of C++'ers.  3 million Java programmers are going to look at D and think "Wow, I can compile it?  Sweet!"

BA

Sorry about the self-post...

Brad Anderson wrote:
> 3 million Java programmers are going to look at D and think "Wow, I can compile it?  Sweet!"

Okay, maybe not all 3 million will look, but hopefully a lot.  And I meant 'compile it natively'

BA

> 
> 
> Okay, maybe not all 3 million will look, but hopefully a lot.  And I meant 'compile it natively'
> 
> BA

Well, I'm expecting there's going to be a lot of hidden problems that will need to fixed once the compile/link phase is complete.  I don't know how this particular issue will affect the SWT port; I'm thinking that when class methods are called with the correct number of arguments, the intuitive meaning is that the most recent subclass method (of the same name) is going to be called.  It's more clear to use an explicit method reference anyway.  It could get confusing otherwise which method is being called.  I don't know; I just think it's better to have to call b.foo() explicitly from class C if there's functionality you need from the superclass.  At least people examining the code know exactly what's going on.  I guess if SWT does make use of overloaded methods this way, it could be tricky to catch it and make the appropriate D conversion. But then the D code will be more readable than the Java code when it's done :-).

John Reimer wrote:

[...]
> But then the D code will be more readable than the Java code when it's done :-).

I totally agree with you. There was just a discussion about sequenced default valued parameters. One argument was, that the coder must simply not be aware of them, when coding. This argument holds here in the other way round:

a coder might just not be aware of the fact, that he overrides a member with the same name of the superclass, because he is simply not aware of the fact, that there is one. Then providing the function call with a wrong typed argument, which causes no error, because there is a matching function in the superclass, may result in a desaster.

By explicitely importing the overloaded functions the coder states, that he knows of them and wants to extend their functionality.

On the other hand the current implementation provides a mechanism to block unwanted functionality. How could this achieved by a java like approach?

So long!