Bug 4435 – Multiple-inheritance of Interfaces results in final/static method/function hijacking

Status
NEW
Severity
normal
Priority
P3
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2010-07-07T07:34:47Z
Last change time
2024-12-13T17:52:29Z
Keywords
accepts-invalid
Assigned to
No Owner
Creator
Rob Jacques
Moved to GitHub: dmd#18278 →

Comments

Comment #0 by sandford — 2010-07-07T07:34:47Z
Essentially, the first matching final/static function is chosen when a class implements two interfaces with final/static methods: interface Alive { final bool isDead() { return false; } } interface Dead { final bool isDead() { return true; } } class Cat1 : Alive, Dead {} class Cat2 : Dead , Alive{} void main(string[] args) { Cat1 c1 = new Cat1; Cat2 c2 = new Cat2; assert(!c1.isDead); assert( c2.isDead); } This seems to be another case of function hijacking. It may be similar in root cause to bug 3706: delegates of interfaces with multiple inheritance fail
Comment #1 by issues.dlang — 2010-07-07T10:44:57Z
Per TDPL, you should have to call these with the syntax c1.Alive.isDead() and c1.Dead.isDead() and c1.isDead() is disallowed. So, obviously the current version of dmd doesn't match TDPL in that respect. Also, I should point out that per TDPL, to call either of them as isDead without parens like you did would require the functions to be marked with @property, otherwise you would have to have parens. DMD doesn't actually require that yet. It would, however, raise the question of what to do in the case where one of the two interfaces had isDead() declared as a property while the other declared it as a non-property function. Would isDead call the property version and isDead() call the non-property version, or would both be disallowed? Regardless, it is a bit bizarre to allow interfaces to have properties when they can't have member variables, since properties emulate public member variables. But I'm not sure that that's really a problem so much as just a bit weird.
Comment #2 by yebblies — 2012-02-06T08:02:17Z
Comment #3 by andrej.mitrovich — 2012-02-06T09:36:28Z
(In reply to comment #2) > https://github.com/D-Programming-Language/dmd/pull/699 This seems to partially overlap Issue 4647. I agree with your implementation, although Kenji seems to think otherwise in 4647. I don't know what Walter thinks though, the pull for 4647 doesn't fix the "ambiguous calls allowed" part of my bug report even though it was closed as fixed. Your pull fixes the "ambigous" part. I'm just trying to make sure we're all on the same page. :)
Comment #4 by yebblies — 2012-02-06T18:47:24Z
(In reply to comment #3) > (In reply to comment #2) > > https://github.com/D-Programming-Language/dmd/pull/699 > > This seems to partially overlap Issue 4647. I agree with your implementation, > although Kenji seems to think otherwise in 4647. I don't know what Walter > thinks though, the pull for 4647 doesn't fix the "ambiguous calls allowed" part > of my bug report even though it was closed as fixed. Your pull fixes the > "ambigous" part. > > I'm just trying to make sure we're all on the same page. :) I'm pretty sure the call should be disallowed, it is ambiguous. Places like this where behavior depends on order of declarations are generally bugs. Note that my patch still needs some work.
Comment #5 by yebblies — 2012-04-13T20:40:27Z
I think the direction of my patch was wrong, overload sets can't be used for this.
Comment #6 by verylonglogin.reg — 2015-04-02T09:33:51Z
*** Issue 5060 has been marked as a duplicate of this issue. ***
Comment #7 by robert.schadek — 2024-12-13T17:52:29Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18278 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB