Re: Entity and Identity

On Jul 27, 4:02 pm, Nilone <rea..._at_gmail.com> wrote:
> On Jul 27, 3:18 am, David BL <davi..._at_iinet.net.au> wrote:
>
>
>
>
>
> > On Jul 25, 4:34 pm, Nilone <rea..._at_gmail.com> wrote:
>
> > > On Jul 25, 12:18 am, rp_at_raampje.(none) (Reinier Post) wrote:
>
> > > > Nilone wrote:
> > > > >[...] OO always needs another paradigm to ride,
> > > > >since it isn't a model of computation but a broken type system mixed
> > > > >with a module system. [...]
>
> > > > You mean abstract data types?
>
> > > What I said there is confused and inaccurate. State machines
> > > obviously are a model of computation.
>
> > > OO classes are used to create data types, since encapsulation,
> > > constructors and attributes are necessary features to create data
> > > types. However, it fails as a type system since it allows subtypes to
> > > be defined that breaks the original type. It also allows for the
> > > creation of reference types, which is an oxymoron.
>
> > > > OO adds inheritance; is that where it breaks?
> > > > (BTW I agree with your criticism of inheritance.)
>
> > > Implementation inheritance copies executable code across the interface
> > > of the class and invites programmers to assume more than promised by
> > > the interface.
>
> > > My rant was against OO classes when used as a type system, although my
> > > sloppy use of the term OO made it seem like more.
>
> > On this newsgroup, the word "type" nearly always means "data type",
> > and not a type of state machine (such as an abstraction of an output
> > stream). IMO it is important and useful to see that there are indeed
> > two fundamentally different kinds of types (and hence two distinct
> > kinds of type hierarchies).
>
> > 1) Data types: Subtyping should follow the D&D subtype as constraint
> > approach. Data types always support comparison operators and
> > assignment to variables of that type.
>
> > 2) State machine "types": Subtyping should follow LSP. LSP by
> > definition means substitutability of one type of state machine for
> > another.
>
> > It is possible to think of variables that hold values to be simple
> > state machines. That fact has tricked much of the OO community into
> > thinking that proper support for 2) makes 1) redundant. However, in
> > actual fact 2) is a very poor approach for representing data types.
> > The big problem is that subtype relationships amongst data types don't
> > map to subtype relationships on the variables that hold them. Most OO
> > programmers don't realise what they're missing. It's not just circle/
> > ellipse cases. For example they miss out on union types, and
> > therefore the basis for algebraic data types. The effect in practise
> > is that nested data types are constructed using dynamic variables and
> > pointers, making the code complex and verbose.
>
> > I think OO languages should distinguish these two independent type
> > hierarchies, and even go as far as demanding comparison and assignment
> > operators on data types and prohibiting them on state machine types.
>
> > Some OO languages only appear to make this distinction. E.g. C# has
> > value types versus reference types. However some data types like
> > strings are reference types and the reference comparison operator is
> > hijacked to instead perform string value comparisons).
>
> Well stated. I especially like the suggestion that languages should
> separate the type hierarchies, which is what I've been trying to say,
> although less successfully.
>
> 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:

1. state machine "type", which refers to interface definition (of method signatures as well as contracted behaviours); and
2. 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. Received on Mon Jul 27 2009 - 12:01:56 CEST