Re: Entity and Identity

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). Received on Mon Jul 27 2009 - 03:18:07 CEST