www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4435] New: Multiple-inheritance of Interfaces results in final/static method/function hijacking

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4435

           Summary: Multiple-inheritance of Interfaces results in
                    final/static method/function hijacking
           Product: D
           Version: D2
          Platform: All
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: sandford jhu.edu



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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 07 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4435


Jonathan M Davis <jmdavisProg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmail.com



10:44:57 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 07 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4435


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid, pull
                 CC|                            |yebblies gmail.com
         AssignedTo|nobody puremagic.com        |yebblies gmail.com
         OS/Version|Windows                     |All



https://github.com/D-Programming-Language/dmd/pull/699

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 06 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4435


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com



09:36:28 PST ---


 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. :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 06 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4435








 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 06 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4435


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|pull                        |
         AssignedTo|yebblies gmail.com          |nobody puremagic.com



I think the direction of my patch was wrong, overload sets can't be used for
this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 13 2012