Re: Separate interface and implemenation problem..
Mark Space wrote:
// also not real code
public static interface MyRunnable {
static void run(); // implicitly public
}
Steven Simpson wrote:
But this marking seems unnecessary. Why does it matter that someone
implements MyRunnable non-statically? The user probably doesn't or
shouldn't (need to) care. If it matters to the implementation, let t=
hat
be it's [sic] own look-out.
Lew wrote:
If it were possible for a nested interface to be non-static, the
client code would care.
Steven Simpson wrote:
Sorry, no, I don't mean that - by 'this marking', I mean Mark's explicit
declaration that an interface type should be only be used in an
'implements static' clause, not a plain 'implements'.
Okay, I was confused by the remark,
That first 'static' is already allowed, and has a meaning, though I
which applies to nested classes. At this time no top-level type can
have a 'static' keyword.
I guess that means I miss your point, though. Client code most
assuredly cares whether a method is static or instance-level. In the
former case it invokes the method via the type name; in the latter it
instantiates an owning object through which to invoke the method.
The problem I have with the suggestion of a "static interface" is that
the suggestion to implement a static method in a concrete class
doesn't make sense. It's a very fundamental change to Java to have
"abstract static" methods. There is no override mechanism for static
methods. I foresee all kinds of problems if they tried to add one.
To have a non-abstract static method in an interface violates the
intent that an interface be purely abstract.
I agree with your point in that it doesn't seem painful to make an
instance through which to invoke methods. Anyway, aren't global
variables and methods somewhat antithetical to the spirit of object-
orientation?
--
Lew