Re: abstract static methods (again)
On Mon, 19 Oct 2009 19:26:41 +0100, Steven Simpson wrote:
The current plan is to support 'static' on the implementation of whole
interfaces, rather than on individual methods. Given a class such as:
class X implements static Runnable {
public static void run() { ... }
}
...then you could write X.static, and get a normal Runnable on which you
could invoke run(), and it would actually invoke X.run().
Now if you had
class Y extends X {...}
would the compiler enforce that Y provides its own implementation of
static run() method? (My desirable answer would be YES.)
If you had an abstract class
abstract class X implements static Runnable {...},
would the implementation of static method run() still be required? (My
desirable answer would be NO.)
If X was
loaded dynamically, you could get the same Runnable:
Class<?> clazz = Class.forName("X");
if (clazz.meetsContract(Runnable.class)) {
Runnable r = clazz.contractOn(Runnable.class); ...
}
I like this. As opposed to my proposal, this does not require some
'magic' class.
So you can invoke a static method on the dynamically loaded class
without method reflection. And X can be checked at compile-time that it
provides required static methods.
It would work by the compiler generating an extra class when it saw
'implements static'.
Somehow I feel that for consistency any class should support X.static,
not just when it 'implements static' some interface. But I'm curious what
was the motivation for having X.static? I only see usability if it was
allowed to use it on type parameters:
class MyClass<T static implements Runnable> {
...
T.static.run();
...
}
For X, that would be:
class X$static implements Runnable {
public void run() {
X.run();
}
}
Each Class object would have a proxy object (created on demand), which
would be an instance of X$static in this case. By being loaded with the
same ClassLoader as X, the X.run() call would bind to the correct
X#run() static method.
An expression such as:
X.static
...would expand to:
(X$static) X.class.getContractor()
Class#getContractor() would create the proxy or recover a cached one.
Or maybe X.static could just expand to X._static where the line
public static final X$static _static = new X$static();
would be added to class X.
Maybe the OP could check whether his requirements would be met by such a
feature.
If we agreed on the answers to the 2 above questions, then this would met
one part of my requirements, namely enforcing own implementation of
static methods and ease of calling them on dynamically loaded classes. (I
also wanted to enforce constructors, but they could be replaced by static
creator methods.)
The part not met by your proposal is calling static methods (and
constructors) on type parameters. But this would be a big task and
probably the best thing is to wait for reified generics first.