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

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

Rib Rdb wrote:
> On 3/9/06, Joe Emenaker <jo...@em...> wrote:
>   
>> Rib Rdb wrote:
>>     
>>> The main reason IPatch was created was
>>> so people don't have to subclass Patch.
>>>       
>> "so people don't have to" make use of the existing code in Patch and,
>> instead, have to write every method anew? Well, we shouldn't dwell on
>> "how come it wasn't done *this* way?" stuff.
>>     
>
> "so people don't have to" be restricted by the design of the Patch class.
>   
Well, I think Patch should have been a fairly minimal abstract class, 
and then SinglePatch and BankPatch would be subclasses of those with the 
Single- and Bank-specific methods... but I wasn't around when those 
decisions were made, and what's done is done. I'm just saying that there 
was a way to do it that didn't require every new type of patch to have 
to redefine all of the methods *and* which wouldn't overly restrict 
those new types of patches.
>> This would allow us to change the format, or to
>> support various formats. Even if we never decided to change the *file*
>> format again, we could still use the PropertyHolder idea to support
>> other formats for other purposes.... like transmission over the net or
>> copy/paste or something like that.
>>     
>
> I guess I just prefer the extreme programming approach.  Why make it
> more complicated now to support something that we might possibly want
> to use at some point in the future.  I'd rather keep the design simple
> now, and then when it needs to change, find the best design for the
> new requirements.
Well, that's how we got what we have now. Putting everything in core.* 
was a simple design that worked... until things started getting big. The 
current midi layer was a simple design that worked... until multiple 
things (like the midi monitor) needed to be notified of the same sysex 
messages. Now we have a half-dozen logging methods in MidiUtil and 
Actions all feeding into MidiMonitor, and they're getting called from a 
half-dozen other methods in PatchEdit and MidiUtil.

Temporary fixes turn into permanent ones. Simple "just for now" 
solutions get appended to until they're unruly and unmanageable. So, the 
best way to save yourself grief down the road is to make sure that you 
design something now that isn't too complicated to use today, yet 
flexible to accommodate all the stuff you can imagine needing in the future.
> But whatever.  I don't have time to write a new
> parser and XML writer.  If you do, go right ahead.
>   
I have time to write the parser and the XML writer.... and I can write 
the PropertyHolder or whatever we want to call it. All you'd need to do 
is support a read(PropertyHolder) and write(PropertyHolder) for any 
given patch in your XMLDriver code.

- Joe