Object oriented database

On Nov 2, 8:40 am, JOG wrote:
>
> These are the people who are worth discussing data models with
> because, well, they realise OO isn't one, and they have built another
> on top as best they could within its constraints.

I agree that OO isn't a data model. However, this depends on
sufficiently narrow definitions of OO and data. The definition

data = information in a form suitable for machine processing

doesn't seem narrow enough to me because objects have state and one
could say that objects represent information.

Since the misuse of OO is so harmful to the computer industry, I think
it's important to come up with better definitions of terms like
"object" and "data". Maybe this could allow for a decent exchange
with the headless chooks on comp.object. Am I dreaming?

Consider that within a given computational machine, we define

object = identifiable Finite State Machine (FSM)

and

variable = identifiable holder for an encoded value

It follows that every variable is an object because one can interpret
a variable as an FSM whose current state corresponds to the encoded
value and which supports all possible transitions between states
through assignment operations.

However it is not true that every object is a variable. For example,
a mutex object doesn't represent an encoded value, and cannot support
assignment.

It follows that there are two kinds of object types: value-types and
non-value-types. In OO, sub-typing is based on the Liskov
Substitution Principle (LSP) and more specifically on the
substitutability of a reference to a type of FSM, and it can easily be
proven that proper sub-typing of value-types is impossible. In fact a
"pure" OO language tries to ignore the distinction and perhaps even
emphasise the non-value-types. This is hard to justify. Value-types
should be promoted where possible.

If we define

data = encoded value

it is clear that OO has little to do with data models, except in the
case where the objects are just variables that hold encoded values.
Of course someone may say that OO encompasses data models for the same
reason.

Since values can easily compose, it follows for data as well. I see
the RM as just one important way to compose values. However the RM
doesn't have exclusivity on this. For example, a well written matrix
library using C++ templates provides a useful implementation of value-
types (matrices) that are composed from other value-types (eg complex
numbers).

Even though it's possible in some cases for an FSM to be regarded as a
variable encoding a value, it never makes sense to say that a value is
composed out of FSMs. Values are immutable whereas FSMs are not.
FSMs exist in time and space whereas values do not. This makes me
think that D&D has possibly created some confusion by suggesting that
object types are related to attribute types (and not to tuple types -
which they refer to as The First Great Blunder). I would suggest it
is better to just say that objects (ie FSMs) which can have
"behaviour" have nothing to do with either. Furthermore, attribute
types, relation types and tuple types are all value-types.

It is possible to compose complex FSMs from simpler ones. This of
course is the basis behind OO. However there is no algorithm that
can predict the behaviour of all given FSMs, and perhaps this explains
the pejorative one hears that "OO lacks a formal basis". However,
that's tantamount to saying that FSMs lack a formal basis, which is
not true. Is it meant to suggest that FSMs aren't useful? I think
a better pejorative would be to say that most OO programmers use
guesswork and aren't capable of programming complex FSMs without
unexpected behaviours (ie bugs), and therefore they should avoid FSMs
wherever possible (eg by promoting value-types - and more specifically
by the data centric principle).

"David BL" wrote in message

> On Nov 2, 8:40 am, JOG wrote:
>>
>> These are the people who are worth discussing data models with
>> because, well, they realise OO isn't one, and they have built another
>> on top as best they could within its constraints.
>
> I agree that OO isn't a data model. However, this depends on
> sufficiently narrow definitions of OO and data. The definition
>
> data = information in a form suitable for machine processing
>
> doesn't seem narrow enough to me because objects have state and one
> could say that objects represent information.
>

When discussing data with OO people, I think both the OO people and the data
centered people focus on the wrong thing. We insist on finding a mapping
between data and objects. I think that's the wrong place to start. I think
we should start with messages. Every formulation of the OO paradigm starts
out by saying that objects collaborate with each other by exchanging
messages. Describing messages in terms of data is a whole lot simpler, and
less philosophical than describing objects in terms of data. Very very few
of the OO people insist that there's some metaphysical difference between
messages and data.

Instead of describing a database as a repository of persistent objects, we
could describe a database as a repository of persistent messages. These
messages are addressed "to whom it may concern", and that raises some
issues, but they are fairly mundane issues.

Even Alan Kay, originator of OO programming, has said that he
underemphasized messages in his original description of what OOP is all
about. And certainly the early years of OOP, OOD, and even OOA were filled
with examples of very clever objects reduced to near uselessness by obtuse
messaging systems. And the thing that might enable OO systems to scale up
better than they do would be a messaging system that can be revised and
extended without breaking existing objects.

I don't have all the answers here, or even any of the answers. I'm just
trying to get us both started in terms of asking the right questions.






























> emphasise the non-value-types. This is hard to justify. Value-types
> should be promoted where possible.
>
> If we define
>
> data = encoded value
>
> it is clear that OO has little to do with data models, except in the
> case where the objects are just variables that hold encoded values.
> Of course someone may say that OO encompasses data models for the same
> reason.
>
> Since values can easily compose, it follows for data as well. I see
> the RM as just one important way to compose values. However the RM
> doesn't have exclusivity on this. For example, a well written matrix
> library using C++ templates provides a useful implementation of value-
> types (matrices) that are composed from other value-types (eg complex
> numbers).
>
> Even though it's possible in some cases for an FSM to be regarded as a
> variable encoding a value, it never makes sense to say that a value is
> composed out of FSMs. Values are immutable whereas FSMs are not.
> FSMs exist in time and space whereas values do not. This makes me
> think that D&D has possibly created some confusion by suggesting that
> object types are related to attribute types (and not to tuple types -
> which they refer to as The First Great Blunder). I would suggest it
> is better to just say that objects (ie FSMs) which can have
> "behaviour" have nothing to do with either. Furthermore, attribute
> types, relation types and tuple types are all value-types.
>
> It is possible to compose complex FSMs from simpler ones. This of
> course is the basis behind OO. However there is no algorithm that
> can predict the behaviour of all given FSMs, and perhaps this explains
> the pejorative one hears that "OO lacks a formal basis". However,
> that's tantamount to saying that FSMs lack a formal basis, which is
> not true. Is it meant to suggest that FSMs aren't useful? I think
> a better pejorative would be to say that most OO programmers use
> guesswork and aren't capable of programming complex FSMs without
> unexpected behaviours (ie bugs), and therefore they should avoid FSMs
> wherever possible (eg by promoting value-types - and more specifically
> by the data centric principle).
>