[Issue 2565] Should be able to use an inherited method as interface implementation
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=2565 --- Comment #8 from Andrej Mitrovic andrej.mitrov...@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: ---
[Issue 2565] Should be able to use an inherited method as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=2565 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #6 from Andrej Mitrovic andrej.mitrov...@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: ---