Re: Entity and Identity

From: Nilone <reaanb_at_gmail.com>
Date: Mon, 27 Jul 2009 07:25:21 -0700 (PDT)
Message-ID: <40785248-198c-4ff4-aa19-e77b841cfb13_at_m3g2000pri.googlegroups.com>


On Jul 27, 4:03 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Nilone wrote:
> > 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.
>
> 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. Received on Mon Jul 27 2009 - 16:25:21 CEST

Original text of this message