digitalmars.D - what is a usage pattern for "static" in an interface?
- dennis luehring (20/20) Feb 02 2012 like:
- Jonathan M Davis (3/4) Feb 02 2012 The same reason it makes sense in a class. I don't see any difference.
- dennis luehring (3/6) Feb 03 2012 that also my first thought - but why do c#, java (and c++) don't allow i...
- Jonathan M Davis (5/13) Feb 03 2012 C++ doesn't have interfaces, and C# and Java don't allow function
- dennis luehring (8/10) Feb 03 2012 but as you can see in my example - my static function isn't implemented
- dennis luehring (2/12) Feb 03 2012 i think should file an bug report for both
- Jacob Carlborg (5/22) Feb 03 2012 The implementation could come from a different object file. But you
- dennis luehring (25/46) Feb 03 2012 another problem i've found
- deadalnix (3/13) Feb 03 2012 Java will allow it in its next version. This will actually be more
- dennis luehring (2/17) Feb 03 2012 Link?
- deadalnix (16/35) Feb 03 2012 You'll find that conference interesting :
- Paulo Pinto (25/26) Feb 03 2012 From OO design it does not make any sense. I was even't aware that this ...
- deadalnix (5/25) Feb 03 2012 I think this is collateral effet of the qualifier policy of D. For me,
- Jonathan M Davis (10/23) Feb 03 2012 That's not generally true of languages such as Java, C#, and D. static
- bls (2/5) Feb 03 2012 A code snippet please.
- dennis luehring (8/14) Feb 03 2012 http://dlang.org/interface.html
- Timon Gehr (2/28) Feb 03 2012
- Martin Nowak (12/34) Feb 03 2012 It's a bug of the compiler to ignore unapplicaple attributes.
- Marco Leise (8/11) Feb 03 2012 Do you have a good example? Mine are currently all solvable with final
- Zach (3/15) Feb 04 2012 There exists std::list implementations in C++ where length is an
- Jonathan M Davis (6/27) Feb 04 2012 That's why it's good practice to check whether something is empty rather...
- Steven Schveighoffer (23/43) Feb 04 2012 static methods are not polymorphic. The only possible reason to include...
like: public interface test { public static void blub(); } static class test_static: test { private static void blub() { int i = 10; } } int main() { test_static.blub(); return 0; } any idea why static could makes sense in an interface? any example? another thing: why can i public "blub" in the interface and private it in the class?
Feb 02 2012
On Friday, February 03, 2012 08:30:31 dennis luehring wrote:any idea why static could makes sense in an interface? any example?The same reason it makes sense in a class. I don't see any difference. - Jonathan M Davis
Feb 02 2012
Am 03.02.2012 08:40, schrieb Jonathan M Davis:On Friday, February 03, 2012 08:30:31 dennis luehring wrote:and what about the public private thing in my example?any idea why static could makes sense in an interface? any example?The same reason it makes sense in a class. I don't see any difference.
Feb 03 2012
On Friday, February 03, 2012 09:03:21 dennis luehring wrote:Am 03.02.2012 08:40, schrieb Jonathan M Davis:implementations of any kind on interfaces. The same is not true for D.On Friday, February 03, 2012 08:30:31 dennis luehring wrote:any idea why static could makes sense in an interface? any example?The same reason it makes sense in a class. I don't see any difference.and what about the public private thing in my example?It looks like a bug. - Jonathan M Davis
Feb 03 2012
Am 03.02.2012 13:02, schrieb Jonathan M Davis:implementations of any kind on interfaces. The same is not true for D.but as you can see in my example - my static function isn't implemented in the interface scope interface test { static void blub(); <---- } there is no example of an not implemented static in a interface
Feb 03 2012
Am 03.02.2012 13:10, schrieb dennis luehring:Am 03.02.2012 13:02, schrieb Jonathan M Davis:i think should file an bug report for bothimplementations of any kind on interfaces. The same is not true for D.but as you can see in my example - my static function isn't implemented in the interface scope interface test { static void blub();<---- } there is no example of an not implemented static in a interface
Feb 03 2012
On 2012-02-03 13:24, dennis luehring wrote:Am 03.02.2012 13:10, schrieb dennis luehring:The implementation could come from a different object file. But you should get a linker error if it doesn't. -- /Jacob CarlborgAm 03.02.2012 13:02, schrieb Jonathan M Davis:i think should file an bug report for bothimplementations of any kind on interfaces. The same is not true for D.but as you can see in my example - my static function isn't implemented in the interface scope interface test { static void blub();<---- } there is no example of an not implemented static in a interface
Feb 03 2012
Am 03.02.2012 13:38, schrieb Jacob Carlborg:On 2012-02-03 13:24, dennis luehring wrote:another problem i've found interface itest { static void blub(){}; } class A: itest { void blub(){}; } class A overrides (silently) the static blub from the interface with an normal method itest it = new A(); A.blub(); // error - not a static it.blub(); // ok or interface itest { static void blub(){} } class A: itest { static void blub(){} } class A just override blub()Am 03.02.2012 13:10, schrieb dennis luehring:The implementation could come from a different object file. But you should get a linker error if it doesn't.Am 03.02.2012 13:02, schrieb Jonathan M Davis:i think should file an bug report for bothimplementations of any kind on interfaces. The same is not true for D.but as you can see in my example - my static function isn't implemented in the interface scope interface test { static void blub();<---- } there is no example of an not implemented static in a interface
Feb 03 2012
Le 03/02/2012 13:02, Jonathan M Davis a écrit :On Friday, February 03, 2012 09:03:21 dennis luehring wrote:Java will allow it in its next version. This will actually be more powerfull that what exists in D.Am 03.02.2012 08:40, schrieb Jonathan M Davis:implementations of any kind on interfaces. The same is not true for D.On Friday, February 03, 2012 08:30:31 dennis luehring wrote:any idea why static could makes sense in an interface? any example?The same reason it makes sense in a class. I don't see any difference.
Feb 03 2012
Am 03.02.2012 13:55, schrieb deadalnix:Le 03/02/2012 13:02, Jonathan M Davis a écrit :Link?On Friday, February 03, 2012 09:03:21 dennis luehring wrote:Java will allow it in its next version. This will actually be more powerfull that what exists in D.Am 03.02.2012 08:40, schrieb Jonathan M Davis:implementations of any kind on interfaces. The same is not true for D.On Friday, February 03, 2012 08:30:31 dennis luehring wrote:any idea why static could makes sense in an interface? any example?The same reason it makes sense in a class. I don't see any difference.
Feb 03 2012
Le 03/02/2012 14:12, dennis luehring a écrit :Am 03.02.2012 13:55, schrieb deadalnix:You'll find that conference interesting : http://medianetwork.oracle.com/media/show/16999 Also, this link that explain it with code snippet. It is in french, but I'm sure you'll understand at least code snippet if you know java : http://blog.xebia.fr/2011/10/05/les-methodes-virtuelles-dextension-dans-java-8/ I think this functionnality is awesome, and D should provide a way to profide default implementation in interfaces if needed. The most important advantage is to allow an API to evolve without requiring the whole code using it to be rewritten. Here is the way to go : 1/ Add the new methods in the interface, and provide default implementation using the old API (even if it is non optimal). 2/ Warn and then mark the old API as deprecated. 3/ When the codebase had enough time to comply with the new API, you can remove the old API methods.Le 03/02/2012 13:02, Jonathan M Davis a écrit :Link?On Friday, February 03, 2012 09:03:21 dennis luehring wrote:Java will allow it in its next version. This will actually be more powerfull that what exists in D.Am 03.02.2012 08:40, schrieb Jonathan M Davis:implementations of any kind on interfaces. The same is not true for D.On Friday, February 03, 2012 08:30:31 dennis luehring wrote:allow it?any idea why static could makes sense in an interface? any example?The same reason it makes sense in a class. I don't see any difference.
Feb 03 2012
From OO design it does not make any sense. I was even't aware that this is possible in D. Static methods are intented to be used as what is commonly known as class methods in Smalltalk. Methods that are attached to the class class, usually known as metaclass. These methods are then transversal to all instances of a given class and are called by ClassName.Method() . Interfaces don't have implementations per se, they only describe a set of funcionalities that any implementing class is obliged to provide. Hence there is no direct implementation and no difference between instances and metaclasses. D interfaces seem then to provide a mechanism where implementing classes are forced to implement static methods, but since when calling interface methods the form is always Interface.Method(), what is the added benefict to force static method implementations? Which use cases have lead to such decision? -- Paulo "Jonathan M Davis" wrote in message news:mailman.298.1328254901.25230.digitalmars-d puremagic.com... On Friday, February 03, 2012 08:30:31 dennis luehring wrote:any idea why static could makes sense in an interface? any example?The same reason it makes sense in a class. I don't see any difference. - Jonathan M Davis
Feb 03 2012
Le 03/02/2012 11:40, Paulo Pinto a écrit :From OO design it does not make any sense. I was even't aware that this is possible in D. Static methods are intented to be used as what is commonly known as class methods in Smalltalk. Methods that are attached to the class class, usually known as metaclass. These methods are then transversal to all instances of a given class and are called by ClassName.Method() . Interfaces don't have implementations per se, they only describe a set of funcionalities that any implementing class is obliged to provide. Hence there is no direct implementation and no difference between instances and metaclasses. D interfaces seem then to provide a mechanism where implementing classes are forced to implement static methods, but since when calling interface methods the form is always Interface.Method(), what is the added benefict to force static method implementations? Which use cases have lead to such decision? -- PauloI think this is collateral effet of the qualifier policy of D. For me, this doesn't make any sense too, and it is a strong +1 for not allowing that. This is misleading for beginners.
Feb 03 2012
On Friday, February 03, 2012 11:40:53 Paulo Pinto wrote:From OO design it does not make any sense. I was even't aware that this is possible in D. Static methods are intented to be used as what is commonly known as class methods in Smalltalk. Methods that are attached to the class class, usually known as metaclass. These methods are then transversal to all instances of a given class and are called by ClassName.Method() .functions on classes are like any other non-member functions. It's just that they're on the class rather than free functions. Usually, they're put there because what they do relates to the class. That same idea applies equally to function definitions of any kind of interfaces.Interfaces don't have implementations per se, they only describe a set of funcionalities that any implementing class is obliged to provide. Hence there is no direct implementation and no difference between instances and metaclasses.D interfaces _do_ allow for function implementations under certain circumstances. - Jonathan M Davis
Feb 03 2012
On 02/03/2012 04:00 AM, Jonathan M Davis wrote:D interfaces_do_ allow for function implementations under certain circumstances. - Jonathan M DavisA code snippet please.
Feb 03 2012
Am 03.02.2012 13:34, schrieb bls:On 02/03/2012 04:00 AM, Jonathan M Davis wrote:http://dlang.org/interface.html interface D { void bar() { } // error, implementation not allowed static void foo() { } // ok final void abc() { } // ok }D interfaces_do_ allow for function implementations under certain circumstances. - Jonathan M DavisA code snippet please.
Feb 03 2012
On 02/03/2012 11:40 AM, Paulo Pinto wrote:From OO design it does not make any sense. I was even't aware that this is possible in D. Static methods are intented to be used as what is commonly known as class methods in Smalltalk. Methods that are attached to the class class, usually known as metaclass. These methods are then transversal to all instances of a given class and are called by ClassName.Method() . Interfaces don't have implementations per se, they only describe a set of funcionalities that any implementing class is obliged to provide. Hence there is no direct implementation and no difference between instances and metaclasses. D interfaces seem then to provide a mechanism where implementing classes are forced to implement static methods,Nope.but since when calling interface methods the form is always Interface.Method(), what is the added benefict to force static method implementations? Which use cases have lead to such decision? -- Paulo "Jonathan M Davis" wrote in message news:mailman.298.1328254901.25230.digitalmars-d puremagic.com... On Friday, February 03, 2012 08:30:31 dennis luehring wrote:any idea why static could makes sense in an interface? any example?The same reason it makes sense in a class. I don't see any difference. - Jonathan M Davis
Feb 03 2012
On Fri, 03 Feb 2012 08:30:31 +0100, dennis luehring <dl.soluz gmx.net> wrote:like: public interface test { public static void blub(); } static class test_static: test { private static void blub() { int i = 10; } } int main() { test_static.blub(); return 0; } any idea why static could makes sense in an interface? any example? another thing: why can i public "blub" in the interface and private it in the class?It's a bug of the compiler to ignore unapplicaple attributes. http://d.puremagic.com/issues/show_bug.cgi?id=3934 http://d.puremagic.com/issues/show_bug.cgi?id=3118http://blog.xebia.fr/2011/10/05/les->methodes-virtuelles-dextension-dans-java-8/ http://cr.openjdk.java.net/~darcy/DefenderMethods.pdfAllowing default implementations in interfaces is a great to be able to extend interfaces without breaking dependent code and also to simplify class implementation. If override were mandatory in implementation classes we could easily allow implementations in interfaces.
Feb 03 2012
Am 04.02.2012, 02:54 Uhr, schrieb Martin Nowak <dawg dawgfoto.de>:If override were mandatory in implementation classes we could easily allow implementations in interfaces.Do you have a good example? Mine are currently all solvable with final methods in interfaces, like interface ... { ... property size_t length(); property final bool empty() { return length == 0; } }
Feb 03 2012
On Saturday, 4 February 2012 at 05:01:10 UTC, Marco Leise wrote:Am 04.02.2012, 02:54 Uhr, schrieb Martin Nowak <dawg dawgfoto.de>:There exists std::list implementations in C++ where length is an O(n) operation, but empty could still be O(1).If override were mandatory in implementation classes we could easily allow implementations in interfaces.Do you have a good example? Mine are currently all solvable with final methods in interfaces, like interface ... { ... property size_t length(); property final bool empty() { return length == 0; } }
Feb 04 2012
On Saturday, February 04, 2012 10:45:05 Zach wrote:On Saturday, 4 February 2012 at 05:01:10 UTC, Marco Leise wrote:That's why it's good practice to check whether something is empty rather than that its length == 0. Containers can optimize empty when they can't necessarily do the same with length. Often it doesn't matter, but in general, checking for empty is better because of that. - Jonathan M DavisAm 04.02.2012, 02:54 Uhr, schrieb Martin Nowak <dawg dawgfoto.de>:There exists std::list implementations in C++ where length is an O(n) operation, but empty could still be O(1).If override were mandatory in implementation classes we could easily allow implementations in interfaces.Do you have a good example? Mine are currently all solvable with final methods in interfaces, like interface ... { ... property size_t length(); property final bool empty() { return length == 0; } }
Feb 04 2012
On Fri, 03 Feb 2012 02:30:31 -0500, dennis luehring <dl.soluz gmx.net> wrote:like: public interface test { public static void blub(); } static class test_static: test { private static void blub() { int i = 10; } } int main() { test_static.blub(); return 0; } any idea why static could makes sense in an interface? any example? another thing: why can i public "blub" in the interface and private it in the class?static methods are not polymorphic. The only possible reason to include a static method in an interface is purely for namespace purposes. If a static method does not contain an implementation in an interface, it should not compile, because there will never be an implementation for it -- static methods do not go in the vtable. In other words, static methods could be useful inside an interface definition, but they would not be part of the "interface" that an implementing class needs to provide. note that: interface test { public static int blub(){return 5;} } is no different than: int blub() {return 5;} interface test { } except for the namespace blub exists in. I could see a use case for protected static methods in an interface. public ones to a lesser degree, private ones should be outlawed. -Steve
Feb 04 2012