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

[Joe E. <jo...@em...>]

Rib Rdb wrote:
> On 3/7/06, Joe Emenaker <jo...@em...> wrote:
>   
>> Either of those solutions would require that the author of the subclass
>> have an awareness of the inner workings of the patch-saving system that
>> 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.
>> 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.

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 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?

- Joe