Re: [Jsynthlib-devel] XML patch saving....

[Rib R. <ri...@gm...>]

On 3/7/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> > On 3/7/06, Joe Emenaker <jo...@em...> wrote:
> >
> >> Either of those solutions would require that the author of the subclas=
s
> >> have an awareness of the inner workings of the patch-saving system tha=
t
> >> I'm not convinced should be necessary.
> >>
> >
> > How is requiring a call to the super method an unreasonable awareness
> > of the inner workings?
> I didn't say that it was unreasonable... I just said that I'm not
> convinced that it should be necessary.
>
> The biggest problem I see is that, if you forget to call the
> super.write() method in your new class, then all of the superclass data
> isn't saved... and you don't discover it until you've closed the
> patchbasket and tried to reload it again.... at which point, the data is
> not coming back. In most other cases where you have to explicitly use
> the super prefix, its in the constructor, and forgetting to do so is
> usually immediately evident (due to thrown exceptions or a JFrame not
> actually getting instantiated... etc).
>
> Now, granted this is a problem that should only affect someone who's
> authoring a subclass to a implementation of IPatch.... but the
> combination of how easy it would be to forget to call super.write() and
> the consequences for doing so...  well... they worry me.

Any problem with serialization, no matter how it happens is going to
cause problems until try to load it.  By making it happen explicitly,
at least the author should know to look for problems there.

> >> I think we can find a slicker way.
> >>
> > Do you have any suggestions.  I think using introspection to find
> > which attributes to store would be more confusing to a driver author,
> > and very tricky to do correctly.
> >
> I'm not seeing how a driver author needs to be bothered with it.

Sorry, I meant patch author.

> My rough idea of the introspection would work something like this:
> - Get a list of all public getters and setters for the object and make a
> list that combines just the attributes that appear in both lists (so,
> the XML writer would then know all of the attributes that we can save
> now, and also set later in the object at the time we read the XML file).
> - If any of those getters return anything other than String (or any
> other data types we know how to save and restore), then throw an
> exception, or fail, or complain, or do something.
> - Get the data from the getters and save them to the XML.
>
> The benefits here are that, if you subclass an implementation of IPatch,
> it's harder to accidentally disrupt the saving of the data in the
> superclass. In fact, if the superclass declares its data, getters, and
> setters as final, then it might be *impossible* for you to mess it up.
>
> The downside is that the saving of the data just kinda happens "like
> magic". Once the author makes a public getter and setter for some piece
> of data, then it magically starts getting saved. In that respect, it's
> almost like it would be inventing an XML version of serialization.

This has several problems.  For one, the XML setters are not normal
setters: they have to take a string argument.  Someone who just writes
a patch class without knowing about serialization is probably not
going to write this type of setter.  I would think they would have a
harder time trying to find the problem than someone who write a write
method that didn't call super; at least this person would know the
problem is in their write method.
Also, you lose some flexibility.  For example the write method could
do something like this
if (xml.useGzip())
  xml.writeGzippedProperty('gzippedSysex', this.sysex)
else
  xml.writeBinaryProperty('sysex', this.sysex)

And the parser would automatically call the correct setter.  If
getters and setters had to be paired, the getter would have to add
some sort of a marker saying whether the data is zipped, and then the
setter would have to split and switch based on that marker.

> > This is just the simplest solution I could think of without writing a
> > new parser.
>
> Well, I'm all for that. In fact, our two proposals don't seem to differ
> in regards to how the XML gets read, parsed, and sets the values in the
> objects. I think we only differ on how we generate the XML at save time, =
no?

True.