NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/object/3507

Internet Message Format | 1992-09-11 | 11.7 KB

Path: sparky!uunet!mcsun!uknet!gdt!aber!aberfa!pcg
From: [e-mail] (Piercarlo Grandi)
Newsgroups: comp.object,comp.database.theory
Subject: Re: Object-Oriented Methodologies - Class Specifications
Message-ID: <[e-mail]>
Date: 10 Sep 92 16:53:02 GMT
References: <[e-mail]>
Sender: [e-mail] (USENET news service)
Reply-To: [e-mail] (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth
Lines: 234
In-Reply-To: [e-mail]'s message of 8 Sep 92 19: 25:20 GMT
Nntp-Posting-Host: aberdb


NOTE: this is crossposted to comp.database.theory, and the part really
relevant to it is at the end, and is about Wierderhold's quite
extraordinary conjecture that all relations fall into one of seven
quite precise categories.

On 8 Sep 92 19:25:20 GMT, [e-mail] (Sally Shlaer) said:

sally> [e-mail] (Graham Matthews) writes:

graham> Get into a domain like mathematics where every object is related
graham> to every other object in many many ways, and OO begins to show
graham> its failures.

As Sally Shlaer remarks later, this is by no means confined to
mathematics, as any database theory person can attest. Even seemingly
simple cases involve complicated structures. But yes, maths is a good
example, and we are all more or less familiar with it.

sally> In <[e-mail]> [e-mail] (Eric Smith) writes:

eric> If you insist on modelling all possible relationships at once,
eric> then yes, it does get complicated.  But trying to model them
eric> without OO would be far more complicated.

sally> Graham writes:

graham> There are many many more relationships that I cannot model with
graham> inheritance, so I am suggesting that people need to look very
graham> carefully at inheritance.
sally>               ~~~~~~~~~~~

Well, what Graham Matthews is saying here seems to be that if OO is a
step forward in one way (you can describe more clearly *some* types of
relationships), it is also a step backwards (some, or maybe many, other
types of relationships become more awkward to describe).

I tend to agree with this point of view :-); I believe that if one looks
as OO as a decomposition strategy based on relatedness by representation
(full definition available on request) then it is obvious that the
strategy is not universally applicable, no matter how flexible the
supporting notation, because there are many cases where quite clearly a
procedure is equally related to two different representations, or even
two different values.

  Two examples to make this clear, at both the 'type' and 'value' level
  of abstraction: should FloatToInt belong to the Float or Int classes?
  it needs access to both representations _equally_; should '1+3' be seen
  as the '+3' message being sent to 1, the '1+' message being sent to
  '3', the 'cons(1,3)' message being set... and so on.

  Also, my mantra 'independent algebras for specification implementation
  notation' clearly implies a more general decomposition paradigm than
  the OO one, and actually does not imply any specific decomposition
  paradigm at all. But I also reckon that I know a more general yet still
  quite specific decomposition paradigm than the OO one, and it is quite
  unconventional and surprising (anybody taking the bait? :->).

sally> I would suggest instead that we need to look carefully at
sally> *additional techniques* for modeling relationships.

Applause, applause! The data structures within programs are as rule as
complex and sophisticated as those within a databse, and program design
requires *excatly* the same conceptual tools aand attention to data
design as setting up a database. Suggestion seconded!

sally> In my experience, entities in the world are related in very
sally> interesting and complex ways -- and to capture these
sally> relationships accurately requires a much richer topology than can
sally> be attained with hierarchies alone.

Further applause! The database people have known this for ages, it's time
'programmers' got into the act themselves.

But, as we both note below, much of the confusion in this thread (and in
the articles with whom I have been discussing previosuly) stems from not
separating levels of abstraction.

One thing is the structure of relationships between values and another
the structure of the relationships between the properties ('types') of
such values. Another difference is between modeling and implementing, as
you note:

sally> Note that virtually all of the OO *analysis* methods allow you to
sally> model such relationship structures.

In a network or entity-relationship sort of model. In practice most
current OO technology involves a fully general directed navigation
network for relationships between values, a fairly awkward hierarchy
with possibly shared branches for relationships between 'types', and
forests of trees for analysis of data designs.

Database people nowadays make these distinctions all the time; it is
possible to do relational data analysis and then map it onto a network
catalog, and this may well describe a hierarchical data structure.

And thus:

graham> There are many many more relationships that I cannot model with
sally>                                                       ~~~~~
graham> inheritance, so I am suggesting that people need to look very
graham> carefully at inheritance.

sally> But perhaps you meant "implement" rather than "model".  This
sally> suggests to me that we should investigate the pros and cons of
sally> *different* techniques for implementing relationships in various
sally> situations.

I would rather say that we need techniques to both model and implement
relationships.


Incidentally maybe we don't need a different technique at every
abstraction level (value, type, model) or across dimensions (semantics,
implementation, syntax), but surely it can be done. For example in the
database world as a rule one can relational thruout: relational
analysis, relational catalog, relational values.

This naturally for description/modeling; for representation/implementing
one can usually choose between multiple more or less semantically
equivalent but pragmatically different implementations:

sally> Several ways spring to mind:
sally> 1.  Inheritance
sally> 2.  Use a pointer to point to the related object
sally> 3.  Use an instance variable to contain an identifier
sally>     of the related object
sally> 4.  Define a class to implement the relationship, and use
sally>     either a pointer or an instance variable with an
sally>       identifier to link the related objects.

Ah, but to list them in this braindump order runs a risk to help the
confusion prone among us (surely not you, as you later on clearly
demonstrate) to make a big confusion between completely different
dimensions/abstraction levels!  Inheritance is an awkward way to
describe/model relationships between properties of values, pointers are
for representing/implementing relationships between values.

I don't forget that if 'types' are represented themselves as values,
then the relationships between 'types' have to be represented as
relationships between values, but the distinction is strong and remains,
so one should not have as casual an attitude as that displayed by:

sally> (per the suggestion from [e-mail] (Eric Smith):

eric> The trick is to see that relationships are themselves objects.
eric> For example, the ways a line and a circle can relate to each other
eric> are the line-circle relationship, which is a subclass of the
eric> two-geometric -figure relationship.

Well, what you are really suggesting here is to operate a confusion
between an entity and its representation as a value, and the
relationships thereof. I find it dangerous!

When database people query a relational catalog they know damn well that
the values they get back are of a fundamentally different nature from
the values they get from querying the non catalog relations. There is a
lot of difference between values that refer to table and domains and
data that refers to tuples and values.

In many traditional OO languages it is compilers (C++) or runtime
systems (Smalltalk) that contain the meta database that represents the
relationships between 'types' represented as values (e.g. as symbol
table entries or instances of class Class).

This tends to make confusion easier rather than more difficult, because
while data and metadata are of a different nature, they can well be
described in the same way, even in a reflective way, as for example with
relational DBMSes that store the catalog as a set of relations in the
database itself.

sally> 5.  Eric's other suggestion:

eric> For example, a specific relationship is a subclass of
eric> relationship, because it "is a" relationship.  Q.E.D.  The same
eric> logic carries from specific relationships to more specific
eric> relationships.  e.g., the relationship between two animals is a
eric> base class of the relationship between a bear and a bobcat,
eric> because the bear-bobcat relationship "is a" two-animal
eric> relationship.  And the relationship between a bear and a salmon is
eric> a subclass of the mammal-fish relationship, because it "is a"
eric> mammal-fish relationship.  And the mammal-fish relationship itself
eric> is a subclass of the two-animal relationship.  So you start to see
eric> a tiny part of a vast inheritance structure of relationships.

sally> Note that this last idea has a fundamentally different nature, in
sally> that it constructs a class in a different domain (subject matter)
sally> -- the domain of OO (or relational theory, or whatever) and not
sally> the domain of the application (Dog Care and Feeding).

Ah precisely. Further applause!

sally> Is it possible to state guidelines to help a designer decide what
sally> is the best way to implement each of the relationships in the Dog
sally> example above?  I would like to see a discussion on this matter.

Well, the databaase people have something to say about this. They have
not settled all the details (for example I and several others think that
Codd has said something terribly wrong about null values), but a lot of
interesting and helpful technology exists.

My favourite source is Wiederhold "Database design". The first part is
about implementation, and the second is about data design, and is
beautifully done and written. The second part applied virtually
identically to data design in programs, not just in databases, as it is
essentially an issue about our cognitive processes (I was very bemused
to see somebody trying to pontificate on how cognitive processes work
*in general*: "everything is an object", sure), and the database people
have worked a lot on the fundamental issues of knowledge representation.

Widerhold makes an extraordinary contention in the second part of his
book, one that as far as I know has gone largely unnoticed:

  all relations/relationships can be modeled with just seven different
  categories of tables.

He gives absolutely no supporting arguments for this, he just states so,
offering some examples, making it merely a conjecture, but I tend to
believe it.

If one accepts his conjecture, then all one has to do for data design is
to do relational analysis, tag each relation with one of those seven
categories, and then map each of the seven types onto the primitives of
the underlying implementation medium, be it a DBMS of any sort, or a
programming language. This can be done both for data (values) and
metadata (types), along any abstraction level and along any dimension.

Incidentally, that's how I tend to attack data design issues in my
programs (yes, I often do *informal* relational schemas and then I map
them onto records and pointers and hash tables and trees and whatever).
--
Piercarlo Grandi                   | JNET: [e-mail]
Dept of CS, University of Wales    | UUCP: ...!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: [e-mail]