www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - what is a usage pattern for "static" in an interface?

reply dennis luehring <dl.soluz gmx.net> writes:
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
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 03.02.2012 08:40, schrieb Jonathan M Davis:

 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?
Feb 03 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 03, 2012 09:03:21 dennis luehring wrote:

 Am 03.02.2012 08:40, schrieb Jonathan M Davis:

 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.


 




implementations of any kind on interfaces. The same is not true for D.


 and what about the public private thing in my example?


It looks like a bug.

- Jonathan M Davis
Feb 03 2012
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
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
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 03.02.2012 13:10, schrieb dennis luehring:

 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


i think should file an bug report for both
Feb 03 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-02-03 13:24, dennis luehring wrote:

 Am 03.02.2012 13:10, schrieb dennis luehring:

 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


 i think should file an bug report for both


The implementation could come from a different object file. But you 
should get a linker error if it doesn't.

-- 
/Jacob Carlborg
Feb 03 2012
parent dennis luehring <dl.soluz gmx.net> writes:
Am 03.02.2012 13:38, schrieb Jacob Carlborg:

 On 2012-02-03 13:24, dennis luehring wrote:

  Am 03.02.2012 13:10, schrieb dennis luehring:

  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


  i think should file an bug report for both


 The implementation could come from a different object file. But you
 should get a linker error if it doesn't.


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()
Feb 03 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 03/02/2012 13:02, Jonathan M Davis a écrit :

 On Friday, February 03, 2012 09:03:21 dennis luehring wrote:

 Am 03.02.2012 08:40, schrieb Jonathan M Davis:

 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.






 implementations of any kind on interfaces. The same is not true for D.


Java will allow it in its next version. This will actually be more 
powerfull that what exists in D.
Feb 03 2012
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 03.02.2012 13:55, schrieb deadalnix:

 Le 03/02/2012 13:02, Jonathan M Davis a écrit :

  On Friday, February 03, 2012 09:03:21 dennis luehring wrote:

  Am 03.02.2012 08:40, schrieb Jonathan M Davis:

  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.






  implementations of any kind on interfaces. The same is not true for D.


 Java will allow it in its next version. This will actually be more
 powerfull that what exists in D.


Link?
Feb 03 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 03/02/2012 14:12, dennis luehring a écrit :

 Am 03.02.2012 13:55, schrieb deadalnix:

 Le 03/02/2012 13:02, Jonathan M Davis a écrit :

 On Friday, February 03, 2012 09:03:21 dennis luehring wrote:

 Am 03.02.2012 08:40, schrieb Jonathan M Davis:

 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.



 allow it?



 implementations of any kind on interfaces. The same is not true for D.


 Java will allow it in its next version. This will actually be more
 powerfull that what exists in D.


 Link?


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.
Feb 03 2012
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
next sibling parent deadalnix <deadalnix gmail.com> writes:
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?

 --
 Paulo


I 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
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
parent reply bls <bizprac orange.fr> writes:
On 02/03/2012 04:00 AM, Jonathan M Davis wrote:

 D interfaces_do_  allow for function implementations under certain
 circumstances.

 - Jonathan M Davis


A code snippet please.
Feb 03 2012
parent dennis luehring <dl.soluz gmx.net> writes:
Am 03.02.2012 13:34, schrieb bls:

 On 02/03/2012 04:00 AM, Jonathan M Davis wrote:

  D interfaces_do_  allow for function implementations under certain
  circumstances.

  - Jonathan M Davis


 A code snippet please.


http://dlang.org/interface.html

interface D
{
   void bar() { } // error, implementation not allowed
   static void foo() { } // ok
   final void abc() { } // ok
}
Feb 03 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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
prev sibling next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
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=3118


 http://blog.xebia.fr/2011/10/05/les->methodes-virtuelles-dextension-dans-java-8/
 http://cr.openjdk.java.net/~darcy/DefenderMethods.pdf


Allowing 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
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
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
parent reply "Zach" <mips intel.arm> writes:
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>:


 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; }
 	}


There exists std::list implementations in C++ where length is an 
O(n) operation, but empty could still be O(1).
Feb 04 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, February 04, 2012 10:45:05 Zach wrote:

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

 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; }
 	
 	}


 
 There exists std::list implementations in C++ where length is an
 O(n) operation, but empty could still be O(1).


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 Davis
Feb 04 2012
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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