• Dario (21/21) Jun 13 2003 class A
• Walter (5/26) Jun 13 2003 This works like it does in C++, where overloads only happen within the s...
• Dario (7/37) Jun 13 2003 I didn't know that...
• Walter (7/14) Jun 13 2003 I did not wish to change that rule from C++ as it could sow a great deal...
• Ilya Minkov (9/13) Jun 16 2003 because in C++, scopes are usually larger. A whole project is usually wr...
• Walter (7/10) Jun 16 2003 appeal

"Dario" <supdar yahoo.com> writes:

class A
{
 void func() {}
}

class B : A
{
 void func(Object o, int[] a, byte b) {}
}

int main()
{
 B b = new B;
 b.func();
 return 0;
}

dmd test.d
test.d(14): function func (Object o,int[]a,byte b) does not match argument
types ()

What has become of A.func()?
It hasn't been overridden, since if I write tell the compiler to override it
answers:
test.d(8): function func function func does not override any

"Walter" <walter digitalmars.com> writes:

This works like it does in C++, where overloads only happen within the same
scope, not across multiple scopes.

"Dario" <supdar yahoo.com> wrote in message
news:bcchn8$t2h$1 digitaldaemon.com...
 class A
 {
  void func() {}
 }

 class B : A
 {
  void func(Object o, int[] a, byte b) {}
 }

 int main()
 {
  B b = new B;
  b.func();
  return 0;
 }

 dmd test.d
 test.d(14): function func (Object o,int[]a,byte b) does not match argument
 types ()

 What has become of A.func()?
 It hasn't been overridden, since if I write tell the compiler to override

it
 answers:
 test.d(8): function func function func does not override any

"Dario" <supdar yahoo.com> writes:

I didn't know that...
Anyway why shouldn't overload happen across multiple scopes?
I think of overloaded function as they have nothing in common, so this rule
sounds really strange to me.

 This works like it does in C++, where overloads only happen within the

same
 scope, not across multiple scopes.

 class A
 {
  void func() {}
 }

 class B : A
 {
  void func(Object o, int[] a, byte b) {}
 }

 int main()
 {
  B b = new B;
  b.func();
  return 0;
 }

 dmd test.d
 test.d(14): function func (Object o,int[]a,byte b) does not match


argument
 types ()

 What has become of A.func()?
 It hasn't been overridden, since if I write tell the compiler to


override
 it
 answers:
 test.d(8): function func function func does not override any

"Walter" <walter digitalmars.com> writes:

I did not wish to change that rule from C++ as it could sow a great deal of
confusion when C++ programmers transition to D. The rule doesn't cause any
controversy in C++ that I've seen, so there doesn't seem to be a compelling
reason to change it and endure the confusion.

"Dario" <supdar yahoo.com> wrote in message
news:bcd58l$1es1$1 digitaldaemon.com...
 I didn't know that...
 Anyway why shouldn't overload happen across multiple scopes?
 I think of overloaded function as they have nothing in common, so this

rule
 sounds really strange to me.

 This works like it does in C++, where overloads only happen within the

 same
 scope, not across multiple scopes.

Ilya Minkov <Ilya_member pathlink.com> writes:

In article <bcd6g7$1fru$2 digitaldaemon.com>, Walter says...
I did not wish to change that rule from C++ as it could sow a great deal of
confusion when C++ programmers transition to D. The rule doesn't cause any
controversy in C++ that I've seen, so there doesn't seem to be a compelling
reason to change it and endure the confusion.

because in C++, scopes are usually larger. A whole project is usually written in
one namespace. While in D, each source file opens a new namespace.

Obviosly it would be quite evil to be able to do overloads in different scopes.
Just import one library, add another... and whoops! Salad! :>

I believe the possibity to continue a unit across many source files could appeal
to many C++ programmers - but i have no idea whether there's anything like a
clean way to do it.

-i.

"Walter" <walter digitalmars.com> writes:

"Ilya Minkov" <Ilya_member pathlink.com> wrote in message
news:bckn4n$200o$1 digitaldaemon.com...
 I believe the possibity to continue a unit across many source files could

appeal
 to many C++ programmers - but i have no idea whether there's anything like

a
 clean way to do it.

I don't think it's worth it. If I write a module with a bunch of overloaded
functions in it, I expect the overloading in the module to not be influenced
by other random modules the user might combine it with.