Re: abstract static methods (again)
On Wed, 21 Oct 2009 08:30:38 -0700, Lew wrote:
Lew wrote:
How is it even possible for a class to know what type to use for 'V',
when every instance of that class could have a different type
replacement for it?
Tomas Mikula <tomas.mik...@gmail.com> wrote:
Whenever you have an instance myObj of class MyClass<V>, the instance
would know the type of V (it is not true now, but hopefully will be
true someday in the future). Now if you call a method on myObj that
calls a static method (or constructor) on V, the method lookup would be
done with aid of myObj. If static means resolved at compile time, then
yes, this is against the nature of static. I don't know how difficult
it would be to implement, I just suggested it is feasible (and IMO
useful).
Isn't that a violation of the fundamental semantic of 'static' as
"class-wide, does not use an instance to resolve"?
(Yes, it is.)
This is not a compile-time vs. run-time matter, despite your attempt at
misdirection. The semantic of 'static' applies at run time and compile
time, both. It means "class level". You suggest using an
instance-level semantic to resolve the meaning of a 'static' construct.
That is too fundamental a change.
I will just note that it would be using an instance of a different class
than whose static method is called. This instance would be used to obtain
the class. After that, the invocation of it's static method would not use
any instance-level semantics. The code
class MyClass<V extends Vector<V>> {
void doSomething(){
V v = V.zero();
}
}
could be translated to something like
class MyClass<V extends Vector<V>> {
void doSomething(){
// get the class (uses an instance of MyClass, namely 'this')
Class<V> clazz = Class.getTypeParameterClass(this, "V");
// invoke the static method (no instance of V used)
V v = clazz.getMethod("zero").invoke(null);
}
}