Re: Entity and Identity

On Jul 27, 3:39 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Nilone wrote:
> > On Jul 27, 12:01 pm, David BL <davi..._at_iinet.net.au> wrote:
>
> >>On Jul 27, 4:02 pm, Nilone <rea..._at_gmail.com> wrote:
>
> > <...snip...>
>
> >>>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
> >>InputStream.
>
> >>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. Received on Mon Jul 27 2009 - 15:59:17 CEST