[kepler-dev] [Bug 4282] - Duplicate of ptolemy.gui.Top

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4282





------- Comment #9 from welker4kepler at gmail.com  2009-08-27 10:28 -------
"Being able to invoke vergil from the build system is separate functionality
from being able to invoke the module manager from vergil."

First, you are the one that originally suggested that invoking Vergil from the
build system was not important. I was going along with your conflation of the
two issues.

Second, these things are in fact linked, at least as the module manager is
currently implemented. Since the module manager uses the build system, it is
possible to invoke Vergil from it. In fact, it is even easy to do so.
Therefore, your proposed third solution is not workable. It is completely
unacceptable in an installed system where Kepler users cannot be expected to
even know about the build system, much less use it, to have a one-way trip to
Vergil and never be able to return except through use of the build system from
the command-line. But that is precisely what would happen if we removed the
override to Top. 

Now, I happen to be working on the module manager once again. So, it is
possible for me to simply disable the ability to switch to Vergil from the
module manager by detecting the situation where Vergil would be invoked and
disabling the buttons that would allow you to proceed.

This assumes of course, that for ordinary users, switching to Ptolemy from the
module manager GUI is not desirable.  

I am not sure that this issue of overriding Top, which in my view is a trivial
technical issue, is worth removing functionality from the GUI based on the
assumption that the functionality is not useful.

In a more general sense, I think that the issue of overrides is one where
worries are more theoretical than practical. I am not saying that problems
never happen. I am saying they rarely happen and when they do they have a
fairly evident solution. Let us assume you refactored Top such that Ptolemy was
rendered incompatible with Kepler until the override of Top was changed. It
would be very straightforward to fix such a problem, which one would expect to
occur rarely. Yes, module incompatibilities can occur due to overrides. But
even more insidious (because such incompatibilities are not as detectable)
incompatibilities can occur due to the mixing of incompatible jars.

In general, we should look at overrides from a perspective of cost-benefit
analysis where primarily speculative concerns are not given disproportionate
weight. In my whole time working on Kepler, I do not recall a serious bug that
I have had to deal with due to overrides (although I do in fact such bugs to
appear).

Of course, all things being equal, developing hooks, when feasible (here it is
not), is better than overriding. Why increase the probability of
incompatibilities, even if only slightly, if it could be avoided? Also, as the
number of overrides increased, one could expect that the probability of
incompatibilities would become more significant.

However, things are rarely equal. In many cases, developing a hook can be quite
expensive. It isn't always worth devoting developer time to such tasks merely
to avert speculative but real and rather small probabilities of
incompatibilities. Also, issues of timing are very important. If a developer is
working on a related project anyway, it might be more feasible to develop hooks
that render certain overrides unnecessary.

All I am saying is that as I think discussion of Top has illustrated, concern
about overrides is given too much weight by some people. It can be very
expensive to develop hooks or alternative solutions. I think it would rarely be
worth it to remove existing functionality, even if we think that functionality
is relatively rarely invoked, merely to remove an override.