Re: abstract static methods (again)
On Wed, 21 Oct 2009 06:10:02 +0100, Steven Simpson wrote:
Tomas Mikula wrote:
On Mon, 19 Oct 2009 19:26:41 +0100, Steven Simpson wrote:
class X implements static Runnable {
public static void 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.)
My initial answer is 'no'. Y$static would contain:
public void run() {
Y.run();
}
...which would just bind to X#run() if Y didn't provide its own #run().
However, I guess the compiler could enforce it, though I'm not sure if
one would want that in all situations. In its favour, while Y instances
might inherit behaviour available in X instances due to 'Y extends X',
there's no reason for the static aspect of Y to inherit the static
aspect of X, e.g. it does not necessarily follow that Y$static extends
X$static, or that (X implements static Runnable && Y extends X => Y
implements static Runnable). Hmm...
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.)
I would say 'yes', if only since 'abstract' has never affected static
methods.
It's true that it is mixing of notions. I mean something like 'abstract
with respect to static'. Maybe requiring both kinds of abstract to always
appear simultaneously isn't the best idea. Maybe this kind of abstract
could instead be denoted as 'implements abstract static' :)
In fact, since you expect (from the previous question) that any Y which
extends X must provide its own static run(), I don't see a point in
requiring X to 'implements static Runnable' if it's only going to leave
the implementation to a base class.
The point would be to enforce the subclasses to 'implement static'
Runnable. Consider again an abstract class Vector with static method
zero(), which should return a zero vector. Vector alone doesn't need
(even can't reasonably) implement zero(), but it wants to enforce its
implementation in all concrete subclasses.
For instance methods, where Y extends X, it's clear that having an X
reference could mean invoking a Y object, i.e. you have a piece of code
which syntactically only refers to type X but semantically could invoke
Y:
abstract class X { public abstract void doSomething(); } class Y extends
X { ... }
X ref = ...;
ref.doSomething(); // this piece
At run-time, you might be dealing with Y, but statically you have only
X. When do you have an analogous case for static methods?
I don't want to have an analog for static methods. If X 'implements
abstract static' Runnable, I wouldn't want to be able to call X.run() or
X.static.run().
In the dynamic-loading use-case, Y would be explicitly identified by
name (and passed to Class#forName(String)). You then check dynamically
that Y 'implements static Runnable' with a call to
Class#meetsContract(Runnable.class). Anything you say about X is
irrelevant.
Agreed.
In the reified-generics case, you might have a class that requires a
type parameter that 'implements static Runnable':
class Banana<T extends static Runnable> {
{
T.run();
}
}
(Aside: I don't see a point in distinguishing between 'extends' and
'implements' on a type parameter, as only one relationship needs to be
expressed, i.e. Class#isAssignableFrom(Class), which is the same whether
you're dealing with interfaces or classes.)
By 'implements' I meant what you mean by 'extends static'. I just needed
to distinguish it from 'extends' without introducing new keyword.
Then you write 'new Banana<Y>', and the compiler checks that Y
'implements static Runnable', and still X is not involved.
Can you write an example where some code statically uses X and that it
'implements static Runnable', but could actually end up invoking
Y#run()?
I can't. This was not my intention. On the other hand my intention was
that even when you call Y#run() you cannot end up invoking X#run().
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.
Yes. For classes without any 'implements static', the proxy object that
X.static ultimately evaluates to (and which Class#getContractor()
returns) can just be an instance of Object, as there are no interfaces
that it has to conform to.
My intuition was that X.static should allow to invoke any static method
of X, not just the ones that appear in some interface that X statically
implements:
class X implements static Runnable {
public static void run(){...}
public static void another(){...}
}
X.static.another().
Not that this would be of any use, it just would feel natural. But then
you would need to generate X$static class for every class that has a
static method.
But I'm curious what was the motivation for having X.static?
If nothing else, just to ensure that there is a static, type-safe,
compile-time way to obtain the proxy object. If you happen to know X
statically, and that 'X implements static Z', and something accepted a
Z, you could write doSomething(X.static).
As you said, X.static is a comfortable way to call
(X$static) X.class.getContractor().
Though in every concrete use it could be replaced by
X.class.contractOn(SomeInterface.class).
X.static is nice and concise, but IMO omitting it (and Class.getContractor
()) avoids some problems (if you agree that X.static should support all
X's static methods) without using much usefulness.
I only see usability if it was
allowed to use it on type parameters:
class MyClass<T static implements Runnable> {
...
T.static.run();
...
}
As you noted before, this sort of thing seems to require reification,
though it's pretty similar to something in Stefan's last topical blog
entry, where he felt that something could be done without reification.
I will yet need to look at it.
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.
Good idea, though I don't think '_static' is an especially reserved name
(is it?). 'static' would never clash with any real class member, and
we're past syntactic analysis by now, so it should be expressible in
bytecode.
Then X.static could just expand to X.static, or?
One problem might be that Class#getContractor() would have to
reflectively look-up a static field on X, instead of just calling
Class.forName("X$static").newInstance().
Was there any other useful use of Class#getContractor() other than with
resolving X.static? If it now was not necessary for that, getContractor
could be omitted completely.
Also, there was an objection to increased object count, so creating on
demand seemed worthwhile.
I admit.
So, to sum up, the intersection of our ideas seems to be adding method
<T> T contractOn(Class<T> clazz);
to class Class.
This could be implemented as follows:
<T> T contractOn(Class<T> clazz){
return clazz.cast(Class.forName(this.getName() +
"$static").newInstance());
}
But we diverge on the opinion for what classes X there should be class X
$static. You say that only for classes that explicitely state 'implements
static', I say that also for all their subclasses. Further, we diverge on
whether Y$static could end up invoking X's static methods.