[Issue 2565] Should be able to use an inherited method as interface implementation

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2565

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P4

--

[Issue 2565] Should be able to use an inherited method as interface implementation

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2565

Stewart Gordon  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #9 from Stewart Gordon  ---
No explanation given for marking INVALID.  Reopening.

--

[Issue 2565] Should be able to use an inherited method as interface implementation

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2565

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |INVALID

--

[Issue 2565] Should be able to use an inherited method as interface implementation

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2565



--- Comment #8 from Andrej Mitrovic  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:
> 
> > // 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: ---

[Issue 2565] Should be able to use an inherited method as interface implementation

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2565



--- Comment #7 from Stewart Gordon  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:

> // 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: ---

[Issue 2565] Should be able to use an inherited method as interface implementation

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2565


Andrej Mitrovic  changed:

   What|Removed |Added

 CC||andrej.mitrov...@gmail.com


--- Comment #6 from Andrej Mitrovic  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: ---

[Issue 2565] Should be able to use an inherited method as interface implementation

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2565


s...@iname.com changed:

   What|Removed |Added

 CC||s...@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 s...@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.


--