www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Override with function overloads

reply jmh530 <john.michael.hall gmail.com> writes:
In the code below, the second to the last line fails to compile. 
As far as I can tell it is because the override also overrides 
all overloads. I could imagine why it would occur with a virtual 
member function, but I would think it wouldn't be necessary with 
a final one.

 system
unittest
{
     class Foo
     {
         final string bar(double d) { return ""; }
         void bar(int x) { x++; };
     }

     class Foo2 : Foo
     {
         override void bar(int x) { }
     }

     Foo2 foo2 = new Foo2;
     foo2.bar(1);
     string x = foo2.bar(1.0); //error that bar is not callable 
with doubles
     //string x = foo2.Foo.bar(1.0); //this compiles
}
Sep 10
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 09/10/2017 08:14 PM, jmh530 wrote:
 In the code below, the second to the last line fails to compile. As far
 as I can tell it is because the override also overrides all overloads. I
 could imagine why it would occur with a virtual member function, but I
 would think it wouldn't be necessary with a final one.

  system
 unittest
 {
     class Foo
     {
         final string bar(double d) { return ""; }
         void bar(int x) { x++; };
     }

     class Foo2 : Foo
     {
         override void bar(int x) { }
     }

     Foo2 foo2 = new Foo2;
     foo2.bar(1);
     string x = foo2.bar(1.0); //error that bar is not callable with 
doubles
     //string x = foo2.Foo.bar(1.0); //this compiles
 }
Here, the feature called "name hiding" is in effect. Foo2.bar hides all bars from Foo. This is to avoid "function hijacking"[1]. Ali [1] https://dlang.org/hijack.html
Sep 10
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 11 September 2017 at 04:29:39 UTC, Ali Çehreli wrote:
 Here, the feature called "name hiding" is in effect. Foo2.bar 
 hides all bars from Foo. This is to avoid "function 
 hijacking"[1].

 Ali

 [1] https://dlang.org/hijack.html
I suppose my issue is that final should prevent function hijacking because I shouldn't be allowed to override string bar(double d) anyway. It shouldn't be a worry. I did see something in the bugzilla about hijack with default arguments. So I imagine it's not so easy to get right. https://issues.dlang.org/show_bug.cgi?id=6679
Sep 11
parent reply nkm1 <t4nk074 openmailbox.org> writes:
On Monday, 11 September 2017 at 15:13:25 UTC, jmh530 wrote:
 I suppose my issue is that final should prevent function 
 hijacking because I shouldn't be allowed to override string 
 bar(double d) anyway. It shouldn't be a worry.
It has nothing to do with overriding. Consider: import std.stdio; class A { final void foo(int) { writeln("A.foo(int)"); } } class B : A { final void foo(long) { writeln("B.foo(long)"); } } void main() { B b = new B; int n = 1; b.foo(n); } That prints "B.foo(long)", even though foo() was called with an int (tbh, I'd say it's hijacking and shouldn't even compile, like it doesn't with virtual functions - try to remove finals). The compiler starts looking from B, finds name "foo" and tries that without looking any futher into base classes. If you want that, you can do it manually: class Foo2 : Foo { alias bar = super.bar; // bring Foo.bars in scope override void bar(int x) { } }
Sep 11
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 11 September 2017 at 17:59:25 UTC, nkm1 wrote:
 On Monday, 11 September 2017 at 15:13:25 UTC, jmh530 wrote:
 I suppose my issue is that final should prevent function 
 hijacking because I shouldn't be allowed to override string 
 bar(double d) anyway. It shouldn't be a worry.
It has nothing to do with overriding. Consider: [snip]
An interesting example. I'm not sure overriding is the issue so most as what is in the overload set. I think foo(int) is not part of the overload set yet. The compiler is able to cast the long to int and then call the one in class B without needing to look to the base class. The behavior is also the same if you use alias this (below). Would there be any problems with final functions of inherited or alias this types being included in the overload set? import std.stdio; class A { final void foo(int) { writeln("A.foo(int)"); } } class B { A a = new A; alias a this; final void foo(long) { writeln("B.foo(long)"); } } void main() { B b = new B; int n = 1; b.foo(n); }
Sep 11
parent reply nkm1 <t4nk074 openmailbox.org> writes:
On Monday, 11 September 2017 at 18:15:36 UTC, jmh530 wrote:
 An interesting example. I'm not sure overriding is the issue so 
 most as what is in the overload set. I think foo(int) is not 
 part of the overload set yet. The compiler is able to cast the 
 long to int and then call the one in class B without needing to 
 look to the base class. The behavior is also the same if you 
 use alias this (below).
It's just an issue (not really an issue :) of name lookup. First, compiler searches for names, that is, for something called "foo". Then, when it finds "foo" (or several in the same scope), it does overload resolution on them. If those are wrong names, it just reports an error, for example: class A { final void foo(int) { writeln("A.foo(int)"); } } class B : A { string foo = "bar"; } void main() { B b = new B; int n = 1; b.foo(n); } While looking for names, it doesn't even care if "foo" is a function or whatever.
 Would there be any problems with final functions of inherited 
 or alias this types being included in the overload set?
I don't know, maybe don't use alias this :) IMO, it's a really dubious feature...
Sep 11
parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 11 September 2017 at 20:40:30 UTC, nkm1 wrote:
 I don't know, maybe don't use alias this :) IMO, it's a really 
 dubious feature...
I don't think it's an issue of alias this, per se. I think it's just something to be aware of and use your approach of aliasing as necessary. It's basically the same thing as using in C++.
Sep 11