Re: Object oriented database

"David BL" <davidbl_at_iinet.net.au> wrote in message news:023ff274-bb72-4b3d-9ec3-234d74b87c77_at_z6g2000pre.googlegroups.com...
> On Nov 2, 8:40 am, JOG <j..._at_cs.nott.ac.uk> 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).
>
Received on Mon Nov 03 2008 - 16:21:32 CET