From: Eric Armstrong <eric.armstrong@eng.sun.com>
Wayne,
Thanks for the great response. I think you're right that
dynamic configurability creates too many problems. That
can be solved by reading in the "replacement table" during
initialization, and not consulting it after that. That makes
for configurable extensibility, rather than dynamic extensibility.
(If the table were too large to read in, a repository that
supported versioning would ensure that only the version
that was present at start up would be consulted.)
The other issue you raise is more problematic. When do
"implementation costs start to outweigh the benefits".
That is a real concern. With the msg() method approach,
the whole style of programming changes. The use of
casting solves that problem, but can lead to pretty ugly
code. In addition, the necessity of consulting the factory
to obtain objects is one that has to be enforced in the
extensions, or else they will unextendable.
For a really configurable XML editor, though, the flexibility
would seem to be worth the price. (On the other hand,
if we wait 12-18 months, there might not be any need.
There will be enough of a variety of XML editors that
something suitable is likely to exist.)
Wayne Gramlich wrote:
> Eric Armstrong wrote:
> >
> > I'm seeing two requirements for either dynamic or
> > configurable extensibility. (Configurable extensibility
> > is sufficient, but dynamic extensibility seems to fall
> > out as a consequence.)
> >
> > Definitions:
> > Dynamic Extensibility
> > The ability to change an app "on the the
> > fly", while it is execution.
> >
> > Configurable Extensibility
> > The ability to configure the app so that new
> > features and functions are added the next
> > time it starts.
> >
> > The two requirements I see are:
> > a) Class Replacement
> > b) Dynamic Messaging
> [...]
>
> Eric:
>
> This is one of the those "been there, done that" kind of
> moments for me. While there are some computer languages that
> have been defined to support extensive dynamic extensibility
> (e.g. Common Lisp), most of the newer languages like C++
> and Java are not as amenable to the concept as one would like
> to think. For a given computer language, there exists a range
> of implementation possibilities ranging from no dynamic
> extensibility (i.e. configurable extensibility only) to
> complete dynamic extensibility. The trick is to determine
> how far to go for each language before the implementation
> costs start to out-weigh the benefits. Trust me, it is
> quite common to spend hours in a dynamic environment trying
> to track down a bug that is directly as a result of the dynamic
> extension and that would not have occurred if the program
> had been simply been restarted from scratch.
>
> Back when I was technical lead of Sun's SparcWorks product
> (now called programmers workshop) for C and C++ (and
> *groan* FORTRAN), we wrestled with these issues and
> eventually settled on some technology called "fix and
> continue". If you have access to Sun, and can contact
> someone named Thomas Preisler, he can explain it to you
> in detail. (If you do talk with him, please say "hello"
> for me.) With fix and continue technology, someone
> could find a bug in a function/method, fix the code,
> and continue execution using the new code. There were
> restrictions, but they were pretty livable.
>
> There were a number of people who wanted to go much
> further with C++ extensibility (something called the
> Object Binary Interface), but they always kept running
> into pretty severe problems. A complex number class
> can be used as a somewhat contrived example that starts
> to illustrate the problems of dynamic extensibility.
> The first complex class implementation uses the standard
> real and imaginary implementation and the second dynamic
> extension switches over to using a polar representation.
> What happens when your add method gets passed one regular
> version as its self argument and a polar representation
> as the second argument? There are many many additional
> problems associated with the dynamic extension of classes
> that I don't have the patience to type in here.
>
> While the "fix and continue" technology implementation used
> by the programmer's workshop is patented by Sun, there
> are alternative "fix and continue" implementations that
> could be used to avoid infringing on Sun's patent. Given
> the CC list on this message, I'm not too sure that avoiding
> patent infringement is much of an issue.
>
> I hope the message above is useful,
>
> -Wayne
------------------------------------------------------------------------
GET A NEXTCARD VISA, in 30 seconds! Get rates
as low as 0.0% Intro APR and no hidden fees.
Apply NOW!
http://click.egroups.com/1/975/3/_/444287/_/953526664/
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Sun Mar 19 2000 - 20:38:20 PST