Re: abstract static methods (again)
On Oct 19, 4:13 pm, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
wrote:
Tomas Mikula <tomas.mik...@gmail.com> wrote:
On Mon, 19 Oct 2009 07:29:24 +0000, Andreas Leitgeb wrote:
Tomas Mikula <tomas.mik...@gmail.com> wrote:
presence of no-arg constructor in a serializable class would be check=
ed
at compile-time rather than at run-time.
I think this is easily misunderstood. The newly possible compiletim=
e
check would be for compiling the *concrete class* whose name you later
intend to specify dynamically at runtime. This does have some merit.
Still no compiletime check would of course be possible at the place
where you'd *use* that class dynamically, so nothing at all can be
helped about the reflection-part of this story.
The idea here was to automate the reflection.
Sorry, that is a non-starter.
If you know the class at compiletime, you can just use it with
the "new"-operator and have all kinds of compile time checks.
If you don't know the class at compiletime, then neither does the
compiler, so there's nothing the compiler could possibly do for you
beyond what it already does, namely write bytecode to have the JVM
check it all at runtime.
In my original post I noted that the use of Class's newly introduced
method
<T> Implementation<T> asImplementationOf(Class<T> clazz);
would have the restriction that the type T is known at compile time.
In this case, the compiler can generate the bytecode to check if the
'this' class implements T.
Even at runtime, there's no saving: both, interface and existence
of relevant methods and constructors, each have to be checked
separately by the JVM.
Although my major intention was to reduce writing reflective code,
there could also be a run-time saving: as soon as the JVM loads a
class A, it will know if it 'statically implements' interface J. (By
the same mechanism as it knows if A implements interface I.)
'Statically implements' would just be a new kind of relationship
between classes, in addition to 'extends' and 'implements'.
I still see some merit in being able to enforce that any concrete
class implementing some thusly declared interface had to offer some
particular c'tor, as a means to help developers of such classes to
not forget about it.
About the static methods: if you need that kind of enforcement for
dynamically used classes, then just use instances and non-static
methods as helpers:
public interface Foo { // known to the user at compiletime.
public void pseudoStatic();}
public class FooBar { // known to the user only at runtime
public void pseudoStatic() { realStatic(); }
public static void realStatic() { /* do something ... */ }}
// snippet of user's code:
Foo x = (Foo)use_reflection_to_get_instance(implName); // implName==
="FooBar"
x.pseudoStatic();
Up to minor syntactical differences this FooBar object does what your
".asImplementationOf()" result was intended to do, if I understood it
correctly.
Yes, but:
- it requires to get an unnecessary instance (not so bad yet);
- getting this instance requires reflection
- using reflection for getting an instance requires conventions
which cannot be checked at runtime (such as the presence of
some particular (e.g. no-arg) constructor)
If I'm interested in just one static method, it turns out I could just
use reflection to get this Method instead of a dummy instance.
Furthermore, if I forget to override pseudoStatic() or realStatic() in
a subclass, I will get the realStatic() from superclass, which is not
what I want. The compiler will not enforce me in any way to override
them.
I don't think, that calling static methods on dynamically
named classes is worth such deep changes as you seem to have in mind
for this task.
The good thing about it is that the changes are not real changes, just
extensions. So far I think they are all backward compatible with
current specification. No old code would be broken if these extensions
are introduced.