Re: Entity and Identity

From: Nilone <reaanb_at_gmail.com>
Date: Sat, 8 Aug 2009 21:51:15 -0700 (PDT)
Message-ID: <e940e336-648f-4815-ba8a-d9d967178042_at_d4g2000prc.googlegroups.com>


On Aug 8, 12:31 am, rp_at_raampje.(none) (Reinier Post) wrote:
> 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.

That's not surprising. Most OO documentation and tutorials use the term to indicate arbitrary classification or similarity. I use the term to indicate a domain of values with defined semantics, and to the construction of such a domain in a programming language. I'll stand by my definition until I see a better one.

>
> >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.

Take a look at my other post. I believe the type system I described there is properly polymorphic. If you give an example, I'll describe it in terms of that system. Received on Sun Aug 09 2009 - 06:51:15 CEST

Original text of this message