Re: Another, is it a bug?
On Wednesday, 16 September 2015 at 03:48:59 UTC, Random D user wrote: Yeah... I guess I was expecting it to overload across class boundaries. I mean there's already a member eat in base class and sub class can't override that since it's got different parameters, and it's a function (can't be variable), so the reasonable thing would be to overload it (which is why I tried override to see if it forces/hints overriding/overloading). Instead it creates two ambiguous names of which only one has to be disambiguated to use which seems super error prone. IMO it should just be error/warning. Given that, normally properties are just overloaded methods in D, it's pretty sad classes break this behavior/convention. It's the exact same as in Java, and probably C# as well. I don't know if there's any OOP language that overloads methods between the base and super class. https://ideone.com/En5JEc
Re: Another, is it a bug?
On Wednesday, 16 September 2015 at 13:18:51 UTC, Meta wrote: It's the exact same as in Java, and probably C# as well. I don't know if there's any OOP language that overloads methods between the base and super class. https://ideone.com/En5JEc https://ideone.com/aIIrKM No, there's nothing like that in Java and C#.
Re: Another, is it a bug?
On Wednesday, 16 September 2015 at 14:08:11 UTC, Kagamin wrote: On Wednesday, 16 September 2015 at 13:18:51 UTC, Meta wrote: It's the exact same as in Java, and probably C# as well. I don't know if there's any OOP language that overloads methods between the base and super class. https://ideone.com/En5JEc https://ideone.com/aIIrKM No, there's nothing like that in Java and C#. Oh, whoops, you're right; I forgot to extend Test. My mistake.
Re: Another, is it a bug?
On Wednesday, 16 September 2015 at 02:59:06 UTC, Random D user
wrote:
I'm trying to make a base class with get property and a sub
class with corresponding set property. The value for the base
class is set via constructor.
The intuitive way doesn't seem to work and workarounds are
unnecessarily ugly (considering you'll sprinkle them all over
the codebase).
class Father
{
int eat()
{
return 1;
}
}
class Daughter : Father
{
void eat( int apples ) {}
// int eat() { return super.eat(); }// Workaround A,
works as expected
//override int eat( int apples ) {} // Workaround D,
fails -> Error: function main.Daughter.eat does not override
any function, did you mean to override 'main.Father.eat'?
}
Daughter d = new Daughter();
// BUG? I expected this to work. It seems that compiler doesn't
even look into parent class to see if there's a matching
function.
//int num = d.eat();// Error: function
main.Daughter.eat (int apples) is not callable using argument
types ()
int num2 = (cast(Father)d).eat(); // Workaround B, works as
expected
int num3 = d.Father.eat(); // Workaround C, works as
well
Considering Father defines the function `int eat()` and Daughter
defines the completely different function `int eat(int)`, it
doesn't surprise me. You're not using virtual dispatch when you
do `return super.eat` or `d.Father.eat()`, you're delegating the
method call to the base class.
Re: Another, is it a bug?
On Wednesday, 16 September 2015 at 03:48:59 UTC, Random D user Given that, normally properties are just overloaded methods in D, it's pretty sad classes break this behavior/convention. The D behavior for overloading is different in general: http://dlang.org/hijack.html It basically never overloads across scopes. You need to alias the name into the scope too explicitly
Re: Another, is it a bug?
On Wednesday, 16 September 2015 at 03:17:05 UTC, Meta wrote: Considering Father defines the function `int eat()` and Daughter defines the completely different function `int eat(int)`, it doesn't surprise me. You're not using virtual dispatch when you do `return super.eat` or `d.Father.eat()`, you're delegating the method call to the base class. Yeah... I guess I was expecting it to overload across class boundaries. I mean there's already a member eat in base class and sub class can't override that since it's got different parameters, and it's a function (can't be variable), so the reasonable thing would be to overload it (which is why I tried override to see if it forces/hints overriding/overloading). Instead it creates two ambiguous names of which only one has to be disambiguated to use which seems super error prone. IMO it should just be error/warning. Given that, normally properties are just overloaded methods in D, it's pretty sad classes break this behavior/convention.
Re: Another, is it a bug?
On Wednesday, 16 September 2015 at 03:54:34 UTC, Adam D. Ruppe wrote: On Wednesday, 16 September 2015 at 03:48:59 UTC, Random D user Given that, normally properties are just overloaded methods in D, it's pretty sad classes break this behavior/convention. The D behavior for overloading is different in general: http://dlang.org/hijack.html It basically never overloads across scopes. You need to alias the name into the scope too explicitly Thanks. That pretty much answers directly to all my questions. I tried to look for this info in class docs/reference, but couldn't find it (obviously). I never thought that this would be in "articles".
