[kepler-dev] Copying ptolemy classes instead of extending them

[David Welker]

Hi Debi,

On a totally unrelated note, I was curious why reporting, which looks 
like a module (it even has a module-info and src code) is store at 
kepler/trunk rather than kepler/trunk/modules?

With respect to Christopher's point, I have no opinion about whether you 
should be overwriting versus extending Ptolemy classes in the reporting 
module.

I would point out though, that having a frozen version of these base 
classes would actually be more fragile, since you are working off the 
trunk. In general, I think that overwriting when you are at the trunk is 
more risky than when you are working off a fixed base, like 1.0. If X 
changes, and it depends on a change in Y to support that change, but 
your version of Y is frozen because you chose to overwrite rather than 
extend, then that change in X will break you, where if you chose to 
extent Y rather than overwrite it, it may not have. (It might break you 
in either case, however, because if you override a particular method in 
the class extending Y and that method does not have the support a change 
that X needs, you will break in any case. However, overall, the 
probability of breaking with extending is probably less than with 
overwriting, since in that case you get changes to any methods that you 
do not override.)

Of course, if you really want to avoid breakage, the thing to do is to 
work off an unchanging version of Kepler, like 1.0, instead of off the 
trunk. Then no change in either the trunk of Ptolemy or the trunk of 
Kepler will break you. However, you also will not have instant access to 
the latest features, so there is a trade-off between fragility of your 
build versus getting the latest features and bug fixes. Most people who 
develop modules here at UC Davis work of the 1.0 version of Kepler 
rather than the trunk.

A final point, there are no disadvantages to overwriting versus 
extending when you are working off 1.0 rather than trunk, except for any 
issues you feel exist with respect to overwriting being more confusing. 
Sometimes overriding is more work when you have a lot of private rather 
than protected methods that whatever method you are overriding uses, 
because you either have to copy and paste those private methods into the 
child class or provide your own implementation.

David

> Hi Debi,
> I'm just curious, but why are you copying Ptolemy classes instead of
> extending them?
> I saw Top.java get added a moment ago as well.
>
> In general, copies of classes end up causing problems because
> we end up with two classes with the same name, but different
> functionality.  Also, the copies don't get bug fixes, though
> some would say that having a frozen version of these base classes
> is a good thing.
>
>
> _Christopher
>
> staggs at ecoinformatics.org wrote:
> > Author: staggs
> > Date: 2009-01-12 16:23:41 -0800 (Mon, 12 Jan 2009)
> > New Revision: 16313
> >
> > Added:
> >    trunk/reporting/src/ptolemy/
> >    trunk/reporting/src/ptolemy/vergil/basic/BasicGraphFrame.java
> > Removed:
> >    trunk/reporting/ptolemy/
> >    trunk/reporting/src/ptolemy/vergil/basic/BasicGraphFrame.java
> > Modified:
> >    
> trunk/reporting/src/org/kepler/reporting/gui/ItemsOfInterestPanel.java
> >    trunk/reporting/src/org/kepler/reporting/gui/ReportingGUI.java
> > Log:
> > Moved some classes into a different location
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>