Re: Entity and Identity
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 27 Jul 2009 10:39:34 -0300
Message-ID: <4a6dae1d$0$23749$9a566e8b_at_news.aliant.net>
>>>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.
Date: Mon, 27 Jul 2009 10:39:34 -0300
Message-ID: <4a6dae1d$0$23749$9a566e8b_at_news.aliant.net>
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...> >>>>machine. I'll allow subtyping an interface and implementing a new
>>>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
>>>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? Received on Mon Jul 27 2009 - 15:39:34 CEST