Thread overview
[Issue 2565] New: Interface methods need to be implemented even if base class already have them impelemented
Jan 07, 2009
d-bugmail
Jan 07, 2009
d-bugmail
Jan 07, 2009
d-bugmail
Jan 07, 2009
d-bugmail
Jan 07, 2009
d-bugmail
[Issue 2565] Should be able to use an inherited method as interface implementation
Jan 07, 2009
d-bugmail
Feb 05, 2013
Andrej Mitrovic
Feb 05, 2013
Stewart Gordon
Feb 05, 2013
Andrej Mitrovic
January 07, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2565

           Summary: Interface methods need to be implemented even if base
                    class already have them impelemented
           Product: D
           Version: 2.023
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: 2korden@gmail.com


interface IFoo
{
        int foo();
}

class FooImpl : IFoo
{
        int foo() {
                return 42;
        }
}

class Foo : public FooImpl, public IFoo
{
}

void main()
{
        Foo foo = new Foo();
}

Error: class A.Foo interface function IFoo.foo is not implemented

I believe the following code sample should just work. Otherwise, one have to explicitly override all the interface methods, which is redundant and adds runtime cost.

It could be related to bug 2539.


-- 

January 07, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2565





------- Comment #1 from shro8822@vandals.uidaho.edu  2009-01-07 14:38 -------
This is working as designed. It chould be converted to "enhancement" or closed as invalid


-- 

January 07, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2565


2korden@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement




------- Comment #2 from 2korden@gmail.com  2009-01-07 14:48 -------
(In reply to comment #1)
> This is working as designed. It chould be converted to "enhancement" or closed as invalid
> 

Okay, but I didn't find it in docs.
I know it is not a convincing argument, but C# allows that.


-- 

January 07, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2565





------- Comment #3 from smjg@iname.com  2009-01-07 15:13 -------
*** Bug 2539 has been marked as a duplicate of this bug. ***


-- 

January 07, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2565


shro8822@vandals.uidaho.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal




------- Comment #4 from shro8822@vandals.uidaho.edu  2009-01-07 15:22 -------

It doesn't say it explicitly but it does say:

"All interface functions must be defined in a class that inherits from that interface:"

and

"A reimplemented interface must implement all the interface functions, it does not inherit them from a super class:"

Could be better.

BTW: if you alias an existing function than it will fill in an interface. I think.


-- 

January 07, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2565


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com
           Severity|normal                      |enhancement
            Summary|Interface methods need to be|Should be able to use an
                   |implemented even if base    |inherited method as
                   |class already have them     |interface implementation
                   |impelemented                |




------- Comment #5 from smjg@iname.com  2009-01-07 15:23 -------
I think the reason for this design is to prevent accidental implementation of an interface by an inherited method with completely different semantics.

So, AISI, it should be possible to use an inherited method that happens to have the required name as an interface implementation, including in the case where the inherited method is final, but the means should be explicit.

Issue 502 already describes one possibility.


-- 

February 05, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=2565


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

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


--- Comment #6 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-02-04 17:42:55 PST ---
(In reply to comment #5)
> but the means should be explicit.

This could be implementable via a mixin template, similar to how forwarding constructors were proposed in Issue9066. A general-purpose template could be written which could be used via:

mixin Forward!(BaseClass, "funcName");

And another template which uses it to fix this issue with:

class Foo : public FooImpl, public IFoo
{
    mixin ImplementInterface!(IFoo, FooImpl);

    // which expands to:
    mixin Forward!(FooImpl, "foo");
    mixin Forward!(FooImpl, "bar");

    // which expands to:
    override int foo() { return FooImpl.foo(); }
    override int bar() { return FooImpl.bar(); }
}

Internally it would iterate through all IFoo interface functions and find the matching implementations in FooImpl, and use `Forward` to mixin in a forwarding function.

Or we would have language support. Anyway it should be doable as a library solution for the time being.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 05, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=2565



--- Comment #7 from Stewart Gordon <smjg@iname.com> 2013-02-05 14:03:18 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> > but the means should be explicit.
> 
> This could be implementable via a mixin template, similar to how forwarding constructors were proposed in Issue9066. A general-purpose template could be written which could be used via:
<snip>
>     // which expands to:
>     override int foo() { return FooImpl.foo(); }
>     override int bar() { return FooImpl.bar(); }

Why do you need a mixin to do this?  ISTM you might as well just insert these directly in your code.  In any case, what you're suggesting doesn't seem to me to be an explicit way of using _an_ inherited method as _an_ interface implementation.  Moreover, how does it accommodate the case where FooImpl.foo is final?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 05, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=2565



--- Comment #8 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-02-05 14:09:31 PST ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > but the means should be explicit.
> > 
> > This could be implementable via a mixin template, similar to how forwarding constructors were proposed in Issue9066. A general-purpose template could be written which could be used via:
> <snip>
> >     // which expands to:
> >     override int foo() { return FooImpl.foo(); }
> >     override int bar() { return FooImpl.bar(); }
> 
> Why do you need a mixin to do this?  ISTM you might as well just insert these directly in your code.  In any case, what you're suggesting doesn't seem to me to be an explicit way of using _an_ inherited method as _an_ interface implementation.  Moreover, how does it accommodate the case where FooImpl.foo is final?

Ok fair enough, the mixin definitely has its share of problems.

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