[kepler-dev] @author tags in duplicated code.

[Bertram Ludaescher]

Hi Edward:

I like the idea of extension points, in particular if it allows us to make
"mode-specific" changes to the GUI.
By this I mean that for certain MoCs/directors and/or during certain
*stages* of workflow development the GUI could have different "modes" and
thus behave differently. For example,  (i) Wf design; (ii) Config (e.g. data
binding); (iii)  "Dry-run"/static analysis; (iv) Execution &
Runtime-monitoring; (v) Report generation; and (vi) Provenance browsing
could all be possible distinct stages/modes.

In the simplest case, it might be that a mode is associated with a director
so that features such as "drop-and-replace-actor" and
"drop-and-insert-actor" would apply in some MoCs (say COMAD) but not others
(e.g. FSM).

Or maybe even simpler: When in "Kepler-mode", certain GUI elements and
features are enabled which may or may not be the same as in "Ptolemy-mode"
of the GUI.

Is there a (reasonably simple) way to use achieve this for the current
code-base, e.g., via extension points?
If yes, then we should explore this. I guess the current approach with
overrides that Sven used is a bit of a workaround, until we find some better
alternatives.

Bertram

On Wed, Oct 20, 2010 at 6:10 PM, Edward A. Lee <eal at eecs.berkeley.edu>wrote:

>
>
> On 10/20/10 2:50 PM, Bertram Ludaescher wrote:
>
>> What is the recommended way to experiment with those GUI changes?
>> Making the changes in the "production code" doesn't seem to be an option.
>> So is branching or code-duplication the way to go?
>>
>
> Ideally, this should be done by subclassing.
> Unfortunately, with OO design, often one discovers that the base classes
> don't have the extension points you need. It's better to add extension
> points that facilitate your variant than to duplicate code...
>
>
>  I think there needs to be an easy way to make code changes, extensions,
>> etc in an "experimentation area" of the repository. Sometimes it will
>> make sense to fold those changes back into the general code.
>> In this particular case, I'm not sure. For example replacing one COMAD
>> actor with another one is easy since the single input, single output
>> structure of actors, together with scope parameters makes this
>> replacement meaningful / conceptually easy. This might not be the case
>> for general models / workflows.
>>
>
> The problem is that it's very rare for people to go back and turn
> "experimental" code into "production" code. If you build experimental
> code, you will always have experimental code...
>
> Edward
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20101028/9588aaf9/attachment-0001.html>