www.digitalmars.com         C & C++   DMDScript  

D - BUG 0.66

reply "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
Jun 13 2003
parent reply "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
Jun 13 2003
parent reply "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
Jun 13 2003
parent reply "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.
Jun 13 2003
parent reply 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.
Jun 16 2003
parent "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.
Jun 16 2003