Re: Entity and Identity
Date: Sun, 26 Jul 2009 23:03:09 -0700 (PDT)
On Jul 26, 9:18 pm, 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
> 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).
Strings may be reference types, but they are immutable and therefore behave more like value types. I think they are only implemented as reference types in order to optimize method calls: copying a huge string onto the stack would take a lot more cpu cycles then copying just a pointer into the heap, and implementing a method that returns a string on the stack would require either that the stack frame to have had preallocated the space required for the returned string or that the method be able to resize its own stack frame. It is the fact that instances of value types are immutable in the same way that strings are immutable that sets them apart from instances of types that aren't. Received on Mon Jul 27 2009 - 08:03:09 CEST