Re: Entity and Identity
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 27 Jul 2009 12:39:35 -0300
Message-ID: <4a6dca3e$0$23747$9a566e8b_at_news.aliant.net>
>>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?
Date: Mon, 27 Jul 2009 12:39:35 -0300
Message-ID: <4a6dca3e$0$23747$9a566e8b_at_news.aliant.net>
Nilone wrote:
> 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.
I respectfully suggest one can counter it more directly with far fewer words. Received on Mon Jul 27 2009 - 17:39:35 CEST