From: Godmar Back (gback@cs.utah.edu)
Date: Mon Jan 25 1999 - 21:40:49 EST
Tim,
> >
> > For instance, what if you simply subclassed ObjectOutputStream and provided
> > a different writeFloat, for instance? It's not final, is it?
>
> Probably not - but I wanted to provide XML serialization as an implementation of
> serialization like SocketImpl provides the implementation to Socket - the reason
> for this is that you want to be able to be able to create a ObjectOutputStream as
> before. This also means that our serialization forms would need to use the extra
> tag to be useful, and that's non-standard. Hmm, I'm not making myself clear
> here...
Okay, but if a user wants to use it he has to use some non-standard way
to tell the ObjectOutputStream what OOSImpl to use.
Should this be a global property? How do you find the OOSImpl to use for
a given ObjectOutputStream?
>
> >
> >
> > In that case, you would either code like:
> >
> > private void writeObject(ObjectOutputStream s) throws IOException {
> > if (s instanceof XMLOutputStream) {
> > ((XMLOutputStream)s).writeFloat("LOADFACTOR", loadFactor);
> > } else {
> > s.writeFloat(loadFactor);
> > }
> > ...
> > }
>
> I don't like this much because I'm not trying to tie this to XML only - I want to
> be able to use different serialization protocols and I though that the tag would
> be useful in XML but possibly in other too - the above just helps us out in one
> case and isn't terrible extensible.
>
XML was only an example. You could of course do
s/XMLOutputStream/TaggedOutputStream and make XMLOutputStream a subclass of
TaggedOutputStream.
>
> There's a certain symetry to it all.
>
That's nicely put...
> >
> >
> > On the other hand, doing this as part of the serialization may be bound
> > to complicate things... and serialization is hard enough to get right.
> > So maybe it would be a good idea to first get plain serialization working
> > so that we can start fixing up classes to use the proper serial forms, and
> > then look at more fancy things.
>
> Oh I doubt it - the idea would be to seperate off the implementation of
> serialization from the interface. I'm not about to launch into an XML I/O system
> right now, but I don't want to exclude it by writing all those
> readObject/writeObject methods and the having to go back and add lots of tags.
>
That depends on what you consider hard. Fixing up classes to do proper
serialization is what I consider easy, and it can be done gradually.
Getting the basic serialization to work seems harder.
Of course, simply separating things out and move specifics into *Impl
classes might be a good idea anyway, independent of XML.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:48 EDT