Re: abstract static methods (again)
Tomas Mikula wrote:
On Tue, 20 Oct 2009 18:28:45 -0400, 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: [...]
Ah, I was wrong with this. But this only means that the Java's
serialization doesn't use _any_ constructor to create an object.
It uses the no-args constructor for any non-Serializable
superclass of the object being deserialized. Since Object is
not Serializable, it follows that deserialization always invokes
at least one no-args constructor.
But it doesn't invoke any constructor for the "direct"
object itself, no.
Which
means that it uses some tricks not available to the programmer (correct
me if I am wrong).
Right. Among other things, the JVM may invoke private
methods (readObject, for example) of the Serializable class.
You couldn't do that from outside the class, not even by
writing bytecode instead of Java.
In your own serialization framework you would need to
create the object being deserialized, so you would care about the
constructors available on your class, not the superclass.
If you want to implement your own scheme for pickling and
reconstituting objects, others have suggested factory methods
and/or auxiliary "builder" objects. That might improve the case
for abstract static methods, but I still don't see it as a
persuasive argument for abstract constructors. YMMV.
--
Eric Sosman
esosman@ieee-dot-org.invalid