[kepler-dev] Duplicate Vergil classes

Matt Jones jones at nceas.ucsb.edu
Mon Jun 6 15:58:02 PDT 2005 

Edward:

I am in complete agreement with Shawn -- we really don't want to 
maintain any duplicated code, but our problem has been more related to 
how to manage extension reasonably without impacting the stable ptolemy 
base.  In general we have tried to minimize our changes to the ptolemy 
code to minimize our disruption to your work.  We have plans on making 
substantive changes to the user interface, including consolidation and 
simplification of many of the configuration dialogs and menus in vergil, 
removal and reordering of many UI components, and other additions such 
as those that Shawn mentioned such as semantic typing that are more 
experimental.  We don't want to disrupt your work with these changes, 
and yet we want to accomplish them.  I'm not sure if you'll want the 
changes in future ptolemy releases, and so we would like our extensions 
and changes to be configurable.

In previous changes to BasicGraphFrame, I modified the class to allow 
extension through the configuration so that we could display a tabbed 
pane for searching in the library on the left of the vergil UI.  This 
was relatively simple and straightforward once I understood the 
inheritance hierarchy and extension mechanisms.  As a result we could 
merge our copy of BasicGraphFrame back into the Ptolemy tree, and have 
been planning to do so for some time.  We haven't so far because of 
inertia and because we often want to relase before you are ready with a 
given version of ptolemy, and from our previous conversations we had 
agreed not to preempt the ptolemy release that way.  So in theory this 
type of extension could be used when we want to change the UI, and would 
not result in code duplication, but we simply need to come to an 
agreement on how to do the merges and how this may or may not affect our 
Kepler releases.

However, some of our other changes are more difficult because of the way 
UI components are created in many levels of the inheritance hierarchy. 
The right-click context menus for actors are a good example.   I wanted 
to change the behavior of one of the menu items (Get Documentation) for 
one of our actors.  However, when I looked into it, I decided I would 
have to modify a base class approximately many levels up the inheritance 
tree.  I considered subclassing it, but that would have eliminated the 
neededed behavior of all of the subclasses leading to my actor class, 
which means I would have had to create an entirely parallel hierarchy 
that mimicked the behavior of the original in everything but the method 
that I wanted to change.

After looking into it, I decided that the ptolemy design allowing UI 
components to be created across many levels of the inheritance hierarchy 
was the root problem with extension.   Had the menu items all been 
created in one class, then that class could have been overridden using 
the configuration mechanism that I used in BasicGraphFrame and that is 
used in other parts of ptolemy (such as in creating the configuration 
dialog boxes using createEditor()).  So I think this issue of creating 
UI at several levels of an inheritance hierarchy is the one that needs 
to be solved to allow us make UI extension configurable and to eliminate 
code duplication.

This "non-extensibility because of inheritance" issue may also exist for 
non-UI areas (the TypeLattice and unit system comes to mind), but I 
haven't looked into that as much so I'm not sure.

I'm not sure if this issue with the context menus exists in other areas 
of the UI, but its a critical one for us.  As Shawn requested, I plan on 
discussing an implementation strategy for all of our UI changes at the 
Kepler meeting in June, so it will be very useful to have Christopher 
there to help craft an intelligent approach that is maximally 
maintainable.  I am hoping we can design a way to create all UI 
components in a set of configurable classes instead of doing so far up 
in some inheritance hierarchy (there would be quite a lot of refactoring 
involved in doing this, I think).  In my mind this is a form of 
encapsulation, where creation of the view should be encapsulated in a 
few classes that are replaceable (even UI properties such as window pane 
colors are currently spread all over the UI classes rather than being in 
a centralized UISettings class, making it hard to globally change the 
look and feel of the UI).  Your thoughts on how to accomplish this would 
be incredibly valuable.

Several of us have write access to the ptolemy cvs tree, so once we have 
a strategy worked out that won't be disruptive I'm sure we'll be happy 
to go ahead and check in any code we are currently duplicating and 
integrate better with the ptolemy development tree.

Matt

Edward A. Lee wrote:
> 
> 
> Shawn:
> 
> I sympathize with your concerns.  The basic issue we are facing, I think
> is actually a fairly widely recognized problem, which is that 
> object-oriented
> design has delivered rather disappointing re-use potential.  OO designs are
> not as modular as people had hoped.
> 
> The consequence of this is that I find that when I want to make nontrivial
> extensions to Vergil, I often have to modify the base classes.
> Usually, the base class can be modified in a backward compatible way, so
> I don't break other code, but nonetheless, modifying the base classes
> often proves necessary...  This is probably partly due to flaws in the
> Vergil architecture, but not entirely... Even very good architectures
> (like the Ptolemy II kernel :-) sometimes require this.
> 
> This suggests that we really need to get you to the point of feeling free
> to work on the Ptolemy II code base...
> 
> Edward
> 
> 
> At 09:04 PM 6/4/2005 -0700, Shawn Bowers wrote:
> 
>> Hi Edward,
>>
>> Thanks (Edward and Christopher) for taking the time to respond to this
>> issue.  It is very much appreciated.
>>
>> I just wanted to write this (unfortunately, lengthy) email to try to
>> better clarify the issue we are struggling with in Kepler in terms of
>> extending the GUI (vergil).  (Matt and Bertram, please step in and 
>> correct
>> or fill-in what I say below.)
>>
>> As you probably know, Kepler tries to keep "in-step" with the Ptolemy 
>> cvs.
>> The goal is to build on the strengths of Ptolemy, and provide *new*
>> capabilities for supporting scientific workflows. These capabilities
>> include new actors (most of the code in kepler), metadata support, data
>> and compute-intensive workflow execution and management, workflow design
>> (targeted towards scientists), and even new graphical user interfaces.
>>
>> The bottom line is that Kepler CVS does *not* contain the Ptolemy source
>> (i.e., we don't want to "spawn" or "fork" a version of Ptolemy). Instead,
>> to build kepler, you literally have to download the current Ptolemy
>> source, set up the required paths for Ptolemy, etc.
>>
>> Ideally, when a new version of Ptolemy comes out, no changes to Kepler
>> should be required, and vice-versa: for changes in Kepler, the user
>> shouldn't have to download a new version of Ptolemy.
>>
>> In certain cases, however, we have found that this approach isn't easy,
>> practical, or always understood, and so we have done the dreaded "code
>> duplication."  I totally agree with you that duplicating code in this way
>> is evil ... but it has really been the only way for us to get around
>> certain problems without having to "re-work" the ptolemy source.
>>
>> For instance, a while ago we needed/wanted to add some new token types to
>> the Ptolemy type lattice. Unfortunately, the basic lattice is essentially
>> "hard-coded" (by that I mean you can't dynamically add new types to it).
>> So, we had to modify the type lattice class itself to add new basic 
>> types.
>> We also could have extended the type lattice class through subclassing,
>> however, this would have meant modifying yet even more classes (i.e.,
>> those that instantiate the type lattice, ...).
>>
>> Essentially, I think to perform subclassing (as has been suggested) given
>> the Kepler CVS approach requires "transitive" subclassing up to the main
>> vergil class ... i.e., subclassing the desired class, subclassing all the
>> classes that instantiate that class, subclassing all the classes that
>> instiate those classes, and so on to the "root."
>>
>> We have found similar difficulties with certain GUI components, including
>> the left-hand panel for doing search, and now for adding items to context
>> menus. Some GUI components do provide configuration via MoML files ...
>> e.g., certain Menu items can be added.  This approach is great, 
>> because it
>> means we can extend the GUI without having to "duplicate" code. However,
>> it seems that only certain GUI components provide such mechanisms ...
>> others are "hard-coded" (in a similar sense as the TypeLattice).
>>
>> So, given all of this, I am more than happy to help find and implement a
>> solution that makes it easy for Kepler to extend/configure Ptolemy 
>> without
>> duplicating code.  It isn't clear how to best accomplish this, however.
>>
>> It would be great if during the Kepler developers meeting, since
>> Christopher will be attending, if we could set aside time to talk about
>> the best approach for doing this.  There are probably things that I and
>> others in Kepler don't totally understand in terms of how to best extend
>> Ptolemy, and so if Christopher could give a rundown on the current
>> approaches that would be great too.  As Kepler develops more, I believe
>> these issues will start becoming more and more essential for us to solve,
>> and so if we can provide generic solutions and contribute them back to
>> Ptolemy, that seems like a good thing ... and hopefully would bring us
>> into code-duplication "purgatory" ;-)
>>
>>
>> Shawn
>>
>>
>>
>>
>> On Sat, 4 Jun 2005, Edward A. Lee wrote:
>> >
>> > In theory, it should never be necessary to copy a class and modify
>> > it.  If it can't be subclassed (e.g. the key variable private) then
>> > it should be refactored and then subclassed (e.g. protected accessor 
>> methods
>> > for the private variables should be added).  A common design pattern
>> > used in Ptolemy is the "strategy pattern" where a base class does
>> > something like this:
>> >
>> >     public void bigComplexMethod() {
>> >         ... lots of stuff ...
>> >         doSomething();
>> >         ... lots more stuff ...
>> >    }
>> >    protected void doSomething() {
>> >        // Base class does nothing
>> >    }
>> >
>> > The protected method provides a placeholder for the subclass to
>> > do something...
>> >
>> > Edward
>> >
>> >
>> > At 09:57 AM 6/3/2005 -0700, Shawn Bowers wrote:
>> > >Edward A. Lee wrote:
>> > >>Shawn:
>> > >>The risk here is that if we change IOPortController (which is 
>> likely),
>> > >>Kepler will not see the change.  At a minimum, this means new 
>> features
>> > >>would not be there.  At a maximum, the Kepler build will break...
>> > >>We really need to be using object-oriented design here...
>> > >>Wouldn't it make more sense to subclass?
>> > >
>> > >Well, maybe you could elaborate how that would work exactly. Seems 
>> like at
>> > >some point we would have to rewrite/copy one of the ptolemy classes.
>> > >Unless of course, there was some way to specify which class to use 
>> via a
>> > >config file (which is done, e.g., in the File > New, but not in other
>> > >places, right?)  Or are we missing something more fundamental?
>> > >
>> > >shawn
>> > >
>> > >
>> > >
>> > >
>> > >>Edward
>> > >>At 02:19 PM 6/2/2005 -0700, Shawn Bowers wrote:
>> > >>
>> > >>>Hi Christopher,
>> > >>>
>> > >>>Basically, all I wanted to do was to add a menu item (for the 
>> time being
>> > >>>...) to the right-click menu on ports. I also did the same for 
>> actors.
>> > >>>
>> > >>>I agree that having duplicated code is a bad idea.
>> > >>>
>> > >>>Right now, though, I don't have time to extend ptolemy to make 
>> this more
>> > >>>configurable. Also, the use of right click menus for what I am 
>> adding
>> > >>>may not be the final "entry point" into the additions I'm trying 
>> to make
>> > >>>-- so until that is finalized, I just started "hacking" to get it 
>> up and
>> > >>>running for now ;-)
>> > >>>
>> > >>>I think that we (speaking for the "kepler" project) need 
>> ourselves to
>> > >>>figure out what GUI extensions we ultimately want and then come 
>> up with
>> > >>>a plan for how to achieve these extensions, including any 
>> mechanisms for
>> > >>>making Vergil more extensible/customizable. Right now, I think we 
>> are
>> > >>>still in the "experimental" and "fleshing it out" stage.
>> > >>>
>> > >>>Generally speaking, I think making all right-click menus 
>> customizable
>> > >>>would help a lot ... but that might be a lot of work.
>> > >>>
>> > >>>Thanks,
>> > >>>shawn
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>Christopher Brooks wrote:
>> > >>> > Hi Shawn,
>> > >>> >
>> > >>> > Is there anyway we can modify the parent class in the Ptolemy 
>> II cvs
>> > >>> > repository so that you extend 
>> ptolemy.vergil.actor.IOPortController
>> > >>> > instead of doing a wholesale copy of the class?
>> > >>> >
>> > >>> > If you don't yet have write access to the Ptolemy II cvs 
>> repository,
>> > >>> > I'm more than willing to give it to you so you could add 
>> extension
>> > >>> > points to Ptolemy II.
>> > >>> >
>> > >>> > The reason is that we have gotten in to quite a bit of trouble
>> > >>> > maintenance-wise when we have duplicated code.  The JNI and 
>> Single
>> > >>> > Window code from Thales caused Edward no end of grief when
>> > >>> > he went to update the copied base classes.
>> > >>> >
>> > >>> > Anyway, the up shot is that I'm more than willing to help out
>> > >>> > if we can avoid duplicate code.
>> > >>> >
>> > >>> > _Christopher
>> > >>>_______________________________________________
>> > >>>Kepler-dev mailing list
>> > >>>Kepler-dev at ecoinformatics.org
>> > 
>> >>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev 
>>
>> > >>
>> > >>------------
>> > >>Edward A. Lee
>> > >>Professor, Chair of the EE Division, Associate Chair of EECS
>> > >>231 Cory Hall, UC Berkeley, Berkeley, CA 94720
>> > >>phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
>> > >>eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>> >
>> > ------------
>> > Edward A. Lee
>> > Professor, Chair of the EE Division, Associate Chair of EECS
>> > 231 Cory Hall, UC Berkeley, Berkeley, CA 94720
>> > phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
>> > eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>> >
> 
> 
> ------------
> Edward A. Lee
> Professor, Chair of the EE Division, Associate Chair of EECS
> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720
> phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal

More information about the Kepler-dev mailing list