Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!emory!gatech!bloom-beacon!eru!hagbard!sunic!mcsun!corton!laas!droopy!robert
From: robert@droopy.laas.fr (Robert Valette)
Newsgroups: comp.object
Subject: Re: concurrency control
Message-ID: <5572@laas.laas.fr>
Date: 12 Apr 91 14:46:33 GMT
References: <1991Apr4.215238.14067@bingvaxu.cc.binghamton.edu> <5558@laas.laas.fr> <894@puck.mrcu>
Sender: news@laas.laas.fr
Reply-To: robert@droopy.laas.fr (Robert Valette)
Organization: LAAS-CNRS, Toulouse, France
Lines: 75

In article <894@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes:
>In article <5558@laas.laas.fr> robert@droopy.laas.fr (Robert Valette) writes:
>
>>Our starting point is HOOD (Hierarchical OOD) and its notion of active objects
>>which are provided with OBCSs (OBject Control Structures).
>
>FLAME ON

I respond to the flame!

>HOOD (Hierarchical Object-Oriented Design) is not object-oriented.

TRUE. Let us say that it is object-based. The aimed coding language is ADA
which is not an object-oriented language.

>Its mostly a disguised version of functional decomposition.

I firmly disagree! Although it is possible to start the design
after a functional ``Requirement Analysis'', all the design process
is based on an encapsulation of data and procedures by means of objects.
There is no public data. An object can only send a method request to an other
one and never can directly access its internal data.
The absence of inheritance mechanism does not imply the absence
of objects (see the discussion in this newsgroup about ``object-oriented
and object-based'').

>...: object-oriented systems are not hierarchical.

What is an object-oriented system (OOP, OOL, OOD, OORA etc.)?
It is true that object-oriented languages do not lead to
hierarchically structured software. The inheritance graph can be a tree
but any node can be instantiated as an object of the same level.
In presence of a lot of object classes the absence of a hierarchical
structuring is not necessarily an advantage.
The advantage of HOOD is precisely to introduce a hierarchical visibility
policy among the objects with no connection between it and the
inheritance graph.

It is possible to have two instances of the same object class
which cannot interact directly because they have been designed
within two separate branches of the encapsulation hierarchy.
The benefit is a better structuring, the cost is that reusability
is harder to achieve.

>Hood does not allow recursive use between modules, so your usage graph
>can only be a DAG.  There is no inheritance.  The notation
>distinguishes between `objects' and `data', so if you design a
>`customer' object you cannot then store that in your linked list
>object.  This is all pretty limiting.

The aim of HOOD is an object-based approach in ADA. It is not
adapted to object-oriented languages. However I think that
some ideas of HOOD are interesting.

To conclude, relationship between inheritance, hierarchical structuring,
and concurrency is an issue yet to be analyzed.
See Article 2006 of comp.object, for example:

||>From: cjmchale@cs.tcd.ie (Ciaran McHale)
||Subject: Re: Concurrency vs Inheritence
||Organization: DSG, Dept. of Comp. Sci., Trinity College, Dublin.
||
||This will
||hopefully allow sychronisation code and functional code to be
||inherited/changed independantly of each other.

In the same way what HOOD suggests (to me) is that visibility scope,
synchronization code and functional code could be inherited/changed
independently of each other.

.---------------------------------------------------------------------.
|         Robert VALETTE, LAAS-CNRS, 7 Av. du Colonel Roche,          |
| F-31077 TOULOUSE Cedex France, TEL:++33 61336409, FAX:++33 61553577 |
|                      NET: robert@laas.laas.fr                       |
 ---------------------------------------------------------------------