abstract static methods (again)
in [Java Help]
|
Prev: Java work from home. Remote (telecommuting) jobs in Java.
Next: Zip question: Where are all the extra characters coming fromupon unzipping?
From: Tomas Mikula on 20 Oct 2009 17:34 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.
From: Eric Sosman on 20 Oct 2009 17:37 Tomas Mikula wrote: > On Tue, 20 Oct 2009 12:12:31 -0700, Daniel Pitts wrote: >> Why do you want to enforce a static method to exist in children? I can >> think of no good reason for it. > > And I also want to enforce constructors. I provided two use-cases. > > 1. serialization frameworks. It is already required that a Serializable > class has a no-arg constructor. But this is not required at compile time. You've said this a couple times, but are you sure it's true? This class (with no no-arg constructor) appears to serialize and deserialize just fine: import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.Serializable; public class Serial implements Serializable { private final int value; Serial(int value) { this.value = value; } public static void main(String[] unused) throws IOException, ClassNotFoundException { Serial s1 = new Serial(42); System.out.println("serializing: value = " + s1.value); ByteArrayOutputStream outb = new ByteArrayOutputStream(); ObjectOutputStream outo = new ObjectOutputStream(outb); outo.writeObject(s1); outo.close(); ByteArrayInputStream inb = new ByteArrayInputStream(outb.toByteArray()); ObjectInputStream ino = new ObjectInputStream(inb); Serial s2 = (Serial) ino.readObject(); System.out.println("deserialized: value = " + s2.value); System.out.println("they are " + (s1 == s2 ? "the same object" : "different objects")); } } -- Eric.Sosman(a)sun.com
From: Daniel Pitts on 20 Oct 2009 18:12 Eric Sosman wrote: > Tomas Mikula wrote: >> On Tue, 20 Oct 2009 12:12:31 -0700, Daniel Pitts wrote: >>> Why do you want to enforce a static method to exist in children? I can >>> think of no good reason for it. >> >> And I also want to enforce constructors. I provided two use-cases. >> >> 1. serialization frameworks. It is already required that a >> Serializable class has a no-arg constructor. But this is not required >> at compile time. > > You've said this a couple times, but are you sure it's true? > This class (with no no-arg constructor) appears to serialize and > deserialize just fine: Only the non-Serializable Base of a Serializable class requires a no-args constructor: <http://java.sun.com/javase/6/docs/api/java/io/Serializable.html> > To allow subtypes of non-serializable classes to be serialized, the subtype may assume responsibility for saving and restoring the state of the supertype's public, protected, and (if accessible) package fields. The subtype may assume this responsibility only if the class it extends has an accessible no-arg constructor to initialize the class's state. It is an error to declare a class Serializable if this is not the case. The error will be detected at runtime. > > During deserialization, the fields of non-serializable classes will be initialized using the public or protected no-arg constructor of the class. A no-arg constructor must be accessible to the subclass that is serializable. The fields of serializable subclasses will be restored from the stream. Anyway, if you are developing frameworks, then you might just have to settle for runtime validation of these constraints, or invent your own language that enforces them. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Eric Sosman on 20 Oct 2009 18:28 Daniel Pitts wrote: > Eric Sosman wrote: >> Tomas Mikula wrote: >>> [...] >>> 1. serialization frameworks. It is already required that a >>> Serializable class has a no-arg constructor. But this is not required >>> at compile time. >> >> You've said this a couple times, but are you sure it's true? >> This class (with no no-arg constructor) appears to serialize and >> deserialize just fine: > > Only the non-Serializable Base of a Serializable class requires a > no-args constructor: [...] Right. Which means that if an interface could mandate a specific constructor for its implementing classes, this capability would not solve Serializable's problem at all: It's not the Serializable class that needs the special constructor, but a superclass that *doesn't* implement Serializable. If we get to the point where an interface can impose requirements on the classes that *don't* implement it, I think we've achieved absurdity ;-) There may yet be a reasonable use case for letting an interface or abstract class require specified constructor signatures of the implementing subclasses, but Serializable isn't it. The others I've seen mentioned in this thread don't seem compelling -- but, as I've also said in this thread, my experience with such things is slight. I'm still willing to be convinced; I'm just not convinced yet. -- Eric.Sosman(a)sun.com
From: Daniel Pitts on 20 Oct 2009 18:45
Eric Sosman wrote: > Daniel Pitts wrote: >> Eric Sosman wrote: >>> Tomas Mikula wrote: >>>> [...] >>>> 1. serialization frameworks. It is already required that a >>>> Serializable class has a no-arg constructor. But this is not >>>> required at compile time. >>> >>> You've said this a couple times, but are you sure it's true? >>> This class (with no no-arg constructor) appears to serialize and >>> deserialize just fine: >> >> Only the non-Serializable Base of a Serializable class requires a >> no-args constructor: [...] > > Right. Which means that if an interface could mandate a specific > constructor for its implementing classes, this capability would not > solve Serializable's problem at all: It's not the Serializable class > that needs the special constructor, but a superclass that *doesn't* > implement Serializable. If we get to the point where an interface > can impose requirements on the classes that *don't* implement it, I > think we've achieved absurdity ;-) > > There may yet be a reasonable use case for letting an interface > or abstract class require specified constructor signatures of the > implementing subclasses, but Serializable isn't it. The others I've > seen mentioned in this thread don't seem compelling -- but, as I've > also said in this thread, my experience with such things is slight. > I'm still willing to be convinced; I'm just not convinced yet. > If the problem is "I want to know I can always pass these values in to create an object", then your solution shouldn't be "Use reflection and enforce constructors", it should be "Use a parameterized factory". Same goes for enforcing static method existance. You really should separate that out into its own class: public interface SpecialFactory<T extends SpecialObject> { T createEmpty(); T createFromFoo(Foo foo); } Now, you have no reflective games to play, and your compiler will enforce better behavior. Reflection does have its place, but there are a lot of very useful things you can do without it. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> |