Re: Entity and Identity

From: Bob Badour <>
Date: Mon, 27 Jul 2009 12:39:35 -0300
Message-ID: <4a6dca3e$0$23747$>

Nilone wrote:

> On Jul 27, 4:03 pm, Bob Badour <> wrote:

>>Nilone wrote:
>>>On Jul 27, 3:39 pm, Bob Badour <> wrote:
>>>>Nilone wrote:
>>>>>On Jul 27, 12:01 pm, David BL <> wrote:
>>>>>>On Jul 27, 4:02 pm, Nilone <> wrote:
>>>>>>>I'm concerned about your statement about LSP and subtyping state
>>>>>>>machines. I just don't see how (or why) you would subtype a state
>>>>>>>machine. I'll allow subtyping an interface and implementing a new
>>>>>>>state machine for it.
>>>>>>That's actually what I meant. A "type" of state machine is what you
>>>>>>are calling an "interface". E.g. a SeekableInputStream is a subtype
>>>>>>of a InputStream. It follows that a reference (to a state machine) of
>>>>>>type SeekableInputStream can be upcast to a reference of type
>>>>>>I think of types as completely divorced from implementation (for both
>>>>>>data types and state machine types).
>>>>>>>LSP requires any property provable about objects of the base type to
>>>>>>>be provable of objects of the derived type. Subtyping a state machine
>>>>>>>would have little value, since you wouldn't be able to change any
>>>>>>>behaviour - "any property provable about the base type" would include
>>>>>>>its exact behaviour.
>>>>>>I agree that subclassing a concrete class doesn't make much sense. It
>>>>>>is important to distinguish between:
>>>>>>a) state machine "type", which refers to interface definition (of
>>>>>>method signatures as well as contracted behaviours); and
>>>>>>b) state machine "implementation".
>>>>>>Class hierarchies confuse this distinction by defining both at the
>>>>>>same time. That being said I'm not too surprised that it's common
>>>>>>practise. Separating type and implementation can make for a lot of
>>>>>>repetition. In a language like C++ it also tends to defeat inlining.
>>>>>Limiting inheritance to just interface inheritance, even from concrete
>>>>>classes, would solve that nicely.
>>>>Huh? What the hell does an implementation feature have to do with
>>>>databases or theory or types?
>>>The conflation of fundamental concepts in OO classes causes the
>>>persistent confusion about types that is evident among OO
>>>programmers. I believe this is relevant in a group where types are a
>>>central theme. Anyway, I think this branch of the conversation is
>>>just about done.
>>What makes you think OO classes are relevant in the first place?
> OO classes are believed and used to model types.  Furthermore, the
> original article about O/R mapping clearly showed the consequences of
> a lack of understanding of fundamental concepts.  "Relational
> databases" are often blamed for these problems.  By understanding the
> problems and limits of OO classes, the nonsense about OODBMS can be
> countered.

I respectfully suggest one can counter it more directly with far fewer words. Received on Mon Jul 27 2009 - 17:39:35 CEST

Original text of this message