NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/object/3293

Text File | 1992-08-21 | 3.4 KB | 73 lines

Newsgroups: comp.object
Path: sparky!uunet!projtech!steve
From: [e-mail] (Steve Mellor)
Subject: Domains (Was Re: Class Methods)
Message-ID: <[e-mail]>
Organization: Project Technology, Inc., Berkeley, CA
Date: Fri, 21 Aug 1992 18:19:16 GMT
Lines: 63

.nf
mat>Another minor problem is that only one level of abstraction, that of
mat>your `application,' is clearly visible.  Other levels are placed in
mat>`domains' that are not in their true client-server DAG, or else
mat>wholly subjugated into the `architecture,' which is, in fact, a
mat>language without the expressive power of a real programming language.
.fi

In Chapter 7 of Object Lifecycles, we introduce the concept of a domain
and describe a Domain Chart that shows _multiple_ domains
That is, the client, user, expert,
and analyst all have visibility on  *all* of the domains.
(They may not _want_ to, of course, but that's another matter.)
Therefore, it is not true that 'only one level of abstraction,
that of your application... is clearly visible'.

I don't know what it means to say that 'other levels are placed in domains
that are not in their true client server DAG'.

.nf
mat> But I see a major engineering problem, too.
mat>
mat> Your `architecture' or language embodies the solution abstractions
mat> you need to achieve certain performance goals on a particular platform
mat> (hardware, OS, file system, network, DBMS server, etc.).  For a system
mat> written on Big Iron (or it's equivalent in networked superservers--
mat> Big Ether or Big Driftnet), a system of which there will be relatively
mat> few, like a power grid controller or an Air Traffic Control system,
mat> this may be a good assumption.  The lifetime of the hardware and the
mat> lifetime of the software are pretty much the same.
mat>  ...
mat> Worse, all the assumptions about relative execution cost that were
mat> built into the architecture (the higher-than-the-language-language) are
mat> invalidated and all of the primitives (`templates') that were tuned to
mat> the old assumptions are wrong.  Instead of multiple levels of abstraction,
mat> each expressing one degree of freedom in the combined problem-solution
mat> space, you have one level of abstraction in which you are really free
mat> to program
.fi

I agree with most of this except
(1) 'Instead of multiple levels of abstraction...'  I believe that this is
false for the reasons stated above.
There may be several domains built one on top of another, and
there may even be several architectural domains.
(2)  The whole discussion is written using perjoratives.  I believe that
this is unjustified.  If the terrible things come to pass as described
in the examples, I *want* my system to be built so that I change
*only the domain that is affected by the change in assumptions*.
While what mat says is true ('all the primitives that were tuned to the
old assumptions are wrong'), that is the way it *has to be*.  If you encode
the semantics of a problem in a model or a programming language
and the semantics of the problem change, then *of course* you will have
to change the
encoding.  The problem is to minimize the impact of the change
by localizing the changes within each domain, and to be able to
reuse each domain intact.

In other news, we lost some messages recently owing to lack of spool space.
If there has been any discussion on this subject in the last week,
could you please mail the message to me privately?  Thanks.

Steve