Re: Entity and Identity

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.

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.

In order to substitute one state machine for another, and allow the new machine to behave differently from the old, the calling code is not allowed to assume anything beyond the method signatures declared in the interface. For example, if you've got an interface for a collection, and a Bag state machine that implements it, you can't even assume that the machine will add an item when you tell it to, since the Bag may be substituted with a Set state machine. Received on Mon Jul 27 2009 - 10:02:11 CEST