Re: [Jsynthlib-devel] Two refactoring questions

[William Z. <wrz...@po...>]

My first suggestion is to move all source code into /src.  Optionally,
synthdrivers can be move to /src-synthdrivers or just /synthdrivers in
preparation for the plugin framework.  Synths should be repackaged as well,
so the final directory will actually be
/synthdrivers/org/jsynthlib/synthdrivers/*.

On Thu, Sep 8, 2011 at 9:30 AM, Joe Emenaker <jo...@em...> wrote:

>
> 1 - When I move all of the stuff from "core" into "org.jsynthlib", how
> should it be organized? I'm planning all of the "*ConfigPanel" stuff
> moving into org.jsynthlib.config, and probably all of "*Widget" going
> into org.jsynthlib.widget. Things like Base64 and XMLFileUtils probably
> going into org.jsynthlib.utils. There's a lot more stuff, however, that
> needs a home. Any suggestions for further categorization are welcome.
> I'm thinking that we might also want a dedicated package for the classes
> which the synthdrivers use for superclasses (ie, PatchEditorFrame,
> LibraryFrame, BankEditorFrame, etc.). I've come across some synthdrivers
> which were subclassing some fairly strange frames... possibly because
> they were the first ones that they came across which seemed like they'd
> work or something.
>

These are all excellent ideas.  I might suggest an 'app' package for the
main JSynthLib app, windows, menus, etc.

2 - Some of the classes have their *type* implied in the name. For
> example, there's an abstract class called "AbstractLibraryFrame" and
> there are some interfaces called "IDriver" and "IBankPatch". These
> aren't really the way the base Java libraries do it and, personally, I
> find it confusing (I keep asking myself "What the heck is an 'abstract
> library'?"). My preference would be to rename AbstractLibraryFrame to
> just LibraryFrame, and IDriver to just Driver, etc. Any objections?
>

I agree.  I myself favor systems like "interface Driver" and "abstract class
DriverBase".  The system is then carefully coded to only require Driver so
people can write fully custom implementations, but DriverBase is available
as a starting point.

I understand the reasoning behind names like IDriver and CDriver, but I
always need the docs around when I code, so I've never found that trick
useful.

-Bill Zwicky