Re: Entity and Identity

From: Bob Badour <>
Date: Mon, 27 Jul 2009 11:03:28 -0300
Message-ID: <4a6db3b7$0$23759$>

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? Received on Mon Jul 27 2009 - 16:03:28 CEST

Original text of this message