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

[Matt Jones]

Hi,

Yes, I agree.  The last thing we need is yet more copies of the exp
files.  They've been extremely difficult to maintain and synchronize
even with our one duplicate, and Chad and Christopher have been
working on moving them into the ptolemy tree so that they needn't
diverge needlessly. For Chad and David, under the new build, what is
the strategy for experimental modifications of other modules like
ptolemy, and how do we ensure that these get merged into the trunk or
deprecated?

Matt

On Mon, Jan 12, 2009 at 4:42 PM, David Welker <david.v.welker at gmail.com> wrote:
> 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
>>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~