Re: Entity and Identity

Nilone wrote:

>Types define values. Values aren't mutable, since mutability implies
>a persistent identity beyond the value itself. As soon as you have
>mutability, you have a state machine, and subtyping state machines is
>a problem. Subtyping an interface and creating a new state machine
>for it is fine.

You are using the term 'type' in a different sense than OO languages such as Java and C# do.

>Take a look at
>http://alistair.cockburn.us/Constructive+deconstruction+of+subtyping

The issues with subtyping he points out are very well known among OO developers, and I was well aware of the importance of the difference between single-threaded and concurrent access, but I've never seen it discussed so clearly. (Then again, I don't read OO literature.)

>According to this, subtyping is possible for values (the R usage
>envelope) and single-user state machines (the S envelope). Since
>classes are reference types, single-user state machines can't be
>assumed. As such, I don't consider subtyping of state machines to be
>viable. Behavioural subtyping is an active research field, but I'm
>not aware of a general solution yet.

Well, the most common 'solution' is not to formally define any requirements on the behavior of classes or interfaces at all but merely state them in comments and examples and hope for the best, but I believe this is changing.

>If you need the same functions in different state machines, create an
>instance of the base machine and use its function, or create a
>function library which can be used by both.

But what if you need equivalent, but differently implemented functions? That's what polymorphism is for.

-- 
Reinier