digitalmars.D.bugs - [Issue 2050] New: interfaces should allow final methods with body
- d-bugmail puremagic.com (35/35) Apr 27 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2050
- d-bugmail puremagic.com (6/6) Apr 28 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2050
- d-bugmail puremagic.com (6/10) Apr 28 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2050
- Robert Fraser (10/25) Apr 28 2008 That's true, but the purpose of interfaces is to allow for multiple
- d-bugmail puremagic.com (22/22) Apr 28 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2050
- Robert Fraser (11/41) Apr 28 2008 You should be able to call them on the interface: If you have:
- d-bugmail puremagic.com (5/31) Apr 28 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2050
- Robert Fraser (4/38) Apr 28 2008 Right, but the ambiguity would be caused at no fault of the code being
- d-bugmail puremagic.com (5/6) Apr 28 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2050
- d-bugmail puremagic.com (6/6) May 14 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2050
- d-bugmail puremagic.com (17/17) Apr 04 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2050
- d-bugmail puremagic.com (9/16) Apr 04 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2050
- d-bugmail puremagic.com (9/28) Apr 04 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2050
- d-bugmail puremagic.com (10/10) Jul 07 2010 http://d.puremagic.com/issues/show_bug.cgi?id=2050
- d-bugmail puremagic.com (12/12) Jun 10 2011 http://d.puremagic.com/issues/show_bug.cgi?id=2050
http://d.puremagic.com/issues/show_bug.cgi?id=2050 Summary: interfaces should allow final methods with body Product: D Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: andrei metalanguage.com Consider: interface Foo { void bar(); final void baz() { bar; bar; } } This code doesn't go through on grounds that interfaces cannot define methods with bodies. In fact, final methods don't break any laws of nature because they are not meant to be overriden and, aside from lookup, have the regime of ordinary functions. It would appear that this issue is easy to mitigate: interface Foo { void bar(); } void baz(Foo foo) { foo.bar; foo.bar; } Generally I favor free functions so I'd be happy with the above. But there are two troublesome scenarios: 1. Operators must be members 2. Sutter's NVI idiom (http://www.gotw.ca/publications/mill18.htm) can be implemented more clearly with members than with virtual functions. There are a couple of other bugs applying to NVI in D as well, that I'll post later. --
Apr 27 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2050 That would open the door to the dreaded diamond pattern. You'd just have the compiler generate ambiguity errors in those cases I suppose? --
Apr 28 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2050That would open the door to the dreaded diamond pattern. You'd just have the compiler generate ambiguity errors in those cases I suppose?The diamond pattern can't occur in schemes with single inheritance of implementation. --
Apr 28 2008
d-bugmail puremagic.com wrote:http://d.puremagic.com/issues/show_bug.cgi?id=2050That's true, but the purpose of interfaces is to allow for multiple inheritance in a safe way. Say you have two interfaces, IZombie from Library A and IPirate from Library B. You have a class ZombiePirate that implements both these interfaces. Right now, IZombie has a final method "dance()", and IPirate has the dance() method as virtual. All is well, since a call to an instance's dance() method would result in IZombie.dance()'s implementation being called. But if IPirate suddenly got a dance() implementation, your code would break simply by updating Library B.That would open the door to the dreaded diamond pattern. You'd just have the compiler generate ambiguity errors in those cases I suppose?The diamond pattern can't occur in schemes with single inheritance of implementation.
Apr 28 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2050 aarti interia.pl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aarti interia.pl It seems that same rationale applies to static functions in interfaces. Currently below code doesn't work, as static functions can not have body in interface. --- int a; interface A { static int number() { return a; } } --- Current situation is just plainly wrong as it is possible to put static functions into interfaces and it is not possible to use them at all - linker error is emitted during compilation (what is understandable as static functions are not virtual). --
Apr 28 2008
d-bugmail puremagic.com wrote:http://d.puremagic.com/issues/show_bug.cgi?id=2050 aarti interia.pl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aarti interia.pl It seems that same rationale applies to static functions in interfaces. Currently below code doesn't work, as static functions can not have body in interface. --- int a; interface A { static int number() { return a; } } --- Current situation is just plainly wrong as it is possible to put static functions into interfaces and it is not possible to use them at all - linker error is emitted during compilation (what is understandable as static functions are not virtual).You should be able to call them on the interface: If you have: class B : A {} void main() { A a = new B(); B b = new B(); A.number(); // Should work fine, so here's the bug a.number(); // Maybe should work....? b.number(); // Should NOT work }
Apr 28 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2050d-bugmail puremagic.com wrote:Such cases would be flagged as ambiguous. --http://d.puremagic.com/issues/show_bug.cgi?id=2050That's true, but the purpose of interfaces is to allow for multiple inheritance in a safe way. Say you have two interfaces, IZombie from Library A and IPirate from Library B. You have a class ZombiePirate that implements both these interfaces. Right now, IZombie has a final method "dance()", and IPirate has the dance() method as virtual. All is well, since a call to an instance's dance() method would result in IZombie.dance()'s implementation being called. But if IPirate suddenly got a dance() implementation, your code would break simply by updating Library B.That would open the door to the dreaded diamond pattern. You'd just have the compiler generate ambiguity errors in those cases I suppose?The diamond pattern can't occur in schemes with single inheritance of implementation.
Apr 28 2008
d-bugmail puremagic.com wrote:http://d.puremagic.com/issues/show_bug.cgi?id=2050Right, but the ambiguity would be caused at no fault of the code being compiled, but because something changed in a different module. In many ways, it's similar to hijacking.d-bugmail puremagic.com wrote:Such cases would be flagged as ambiguous.http://d.puremagic.com/issues/show_bug.cgi?id=2050That's true, but the purpose of interfaces is to allow for multiple inheritance in a safe way. Say you have two interfaces, IZombie from Library A and IPirate from Library B. You have a class ZombiePirate that implements both these interfaces. Right now, IZombie has a final method "dance()", and IPirate has the dance() method as virtual. All is well, since a call to an instance's dance() method would result in IZombie.dance()'s implementation being called. But if IPirate suddenly got a dance() implementation, your code would break simply by updating Library B.That would open the door to the dreaded diamond pattern. You'd just have the compiler generate ambiguity errors in those cases I suppose?The diamond pattern can't occur in schemes with single inheritance of implementation.
Apr 28 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2050It seems that same rationale applies to static functions in interfaces.I agree. --
Apr 28 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2050 bugzilla digitalmars.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement --
May 14 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2050 This seems to break composability: interface I1 { final int foo() {return 1;} } interface I2 { final int foo() {return 2;} } class A: I1, I2 {} Whose foo does A choose? And how is it resolved? (given you can't drop one of the interfaces). And consider class B: I1, I2 { final int foo() {return 3;} } B b = new B(); I1 i1 = b; I2 i2 = b; assert( i1.foo == 1 ); assert( i2.foo == 2 ); assert( b.foo == 3 ); --
Apr 04 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2050Consider: interface Foo { void bar(); final void baz() { bar; bar; } }How is this superior to the current interface + mixin approach? Or an mixin-able interface approach?: class A:Foo { mixin Foo; // Add Foo's final/static method bodies to A } --
Apr 04 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2050This seems to break composability: interface I1 { final int foo() {return 1;} } interface I2 { final int foo() {return 2;} } class A: I1, I2 {} Whose foo does A choose? And how is it resolved? (given you can't drop one of the interfaces).I think that's an ambiguity. It might be busted by having A write e.g. alias I1.foo foo;And consider class B: I1, I2 { final int foo() {return 3;} } B b = new B(); I1 i1 = b; I2 i2 = b; assert( i1.foo == 1 ); assert( i2.foo == 2 ); assert( b.foo == 3 );A good use of final functions is to enable the non-virtual interface idiom. The point of that idiom is partially that you cannot override final functions in interfaces. --
Apr 04 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2050 Rob Jacques <sandford jhu.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sandford jhu.edu Wasn't this added in D 2.040. (i.e. should this be closed?) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 07 2010
http://d.puremagic.com/issues/show_bug.cgi?id=2050 yebblies <yebblies gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |yebblies gmail.com Resolution| |FIXED Added in dmd2.040 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 10 2011