Re: Object oriented database

On Nov 2, 8:40 am, JOG <j..._at_cs.nott.ac.uk> wrote:

>

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 valuetypes  (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). Received on Mon Nov 03 2008 - 04:12:39 CET