Re: Date's "First Great Blunder"

From: Eric Kaun <>
Date: Wed, 14 Apr 2004 21:18:25 GMT
Message-ID: <BUhfc.282$>

"mAsterdam" <> wrote in message news:407d5762$0$566$
> Dawn M. Wolthuis wrote:
> > C. J. Date has written about what he calls "The First Great Blunder"
> > to this question: What concept is it in the relational world that is
> > counterpart to the concept of object class in the object world?
> Let's sketch those worlds:
> At some time, ISO chose to define an object as a
> "model of an entity, characterised by behaviour and state." and entity
> being "a thing of interest".
> The dynamics here are very important. Does a relational model
> charactarise behaviour? It surely limits behaviour by means of
> constraints. Maybe it is somehow possible to completely capture
> behaviour in constraints on valid states and valid transitions -
> it is not what it is meant to do.

Why not? Characterizing (modeling) behavior is inherently difficult to model. Many specification languages (Z, Alloy, others) have pre- and postvalues  (e.g. X vs. X', the post-state) that work fairly well.

A specification language meant for dynamic behavior might be Hoare's Communicating Sequential Processes (CSP), but I guarantee such things aren't in the heads of most OO programmers and language designers. Nor are state-transition tools.

> Why throw a sledgehammer at screws?
> Think of an object as a possibly active thing (actor) in the context
> of a running program. This context has a severe limitation. When the
> program stops, the object dies. In order to preserve whatever state
> beyond the running time of the program, the object needs to preserve all
> the data that is necessary to revive at a later time.

And all that assumes that the object is the lexus of meaning, which isn't necessarily true.

> It needs to
> prepare for reincarnation, as it were. Well, just dump (serialize)
> the system image, and restore it the next time the (now different)
> program is run.
> This is exactly what Smalltalk systems used to do (still? I don't know).
> As soon as we want to the object to *share* data with objects in
> different programs, this scheme breaks down.

It also holds the objects accountable to nothing at all - nothing declarative. The constraints in relational are important, for self-documentation, understanding, firewalling problems, etc. We're trying to manage great complexity (and OO apps are very complex, not least because of the value/variable hybrid mutation), and need to give our small heads tools to do so. Computers can check and enforce constraints. Constraints are shorter than code, and when that code is limited to a single method in a single object, a constraint can be spread across multiple objects and methods, making it exponentially (?) harder than a constraint, precondition, postcondition, etc.

> To get back to where I left off: What concept is it in the object world
> that is the counterpart to the concept of relation in the relational
> A vampire's coffin, or something similar. Shared reincarnation (not
> persistence, which disregards the sharing aspect) is beyond
> the scope of looking at data as objects.
> The relational model looks at data as shared pieces of information.
> Structured and with meaning, but passive. Until some outside chain
> of events triggers an update, "nothing ever happens" (- Talking heads).
> Autonomous behaviour is beyond the scope of lookin at data as relations.

Perhaps, but:

1) those are concerns that SHOULD be separated
2) there are tools for looking at each separately
3) as a collective, we don't use those tools anyway
4) objects merge both data and function
5) behavior is required to obey structure (else the structural rules mean

etc. etc.

In short: I don't understand what you're getting at, but I disagree with you anyway. :-)

  • erk
Received on Wed Apr 14 2004 - 23:18:25 CEST

Original text of this message