Re: Entity and Identity
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 28 Jul 2009 10:20:23 -0300
Message-ID: <4a6efb18$0$23754$9a566e8b_at_news.aliant.net>
>>Nilone wrote:
>>
>>>On Jul 28, 1:21 am, rp_at_raampje.(none) (Reinier Post) wrote:
>>
>>>>Nilone wrote:
>>
>>>>>On Jul 25, 10:34 am, Nilone <rea..._at_gmail.com> wrote:
>>
>>>>>>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.
>>
>>>>>I mean mutable types, not reference types.
>>
>>>>Aren't those problems caused by the use of mutability
>>>>rather than OO inheritance? Of course subtypes can break
>>>>the original type, but developers aren't supposed to do that.
>>>>What alternative to inheritance do you propose for sharing
>>>>function implementations across objects of different but related types,
>>>>and how is it any safer?
>>
>>>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.
>>
>>Forget state machines. As soon as you have mutability, you have a
>>variable. Leave it at that.
>
> Nah, that doesn't suit me.
Date: Tue, 28 Jul 2009 10:20:23 -0300
Message-ID: <4a6efb18$0$23754$9a566e8b_at_news.aliant.net>
Nilone wrote:
> On Jul 28, 2:39 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote: >
>>Nilone wrote:
>>
>>>On Jul 28, 1:21 am, rp_at_raampje.(none) (Reinier Post) wrote:
>>
>>>>Nilone wrote:
>>
>>>>>On Jul 25, 10:34 am, Nilone <rea..._at_gmail.com> wrote:
>>
>>>>>>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.
>>
>>>>>I mean mutable types, not reference types.
>>
>>>>Aren't those problems caused by the use of mutability
>>>>rather than OO inheritance? Of course subtypes can break
>>>>the original type, but developers aren't supposed to do that.
>>>>What alternative to inheritance do you propose for sharing
>>>>function implementations across objects of different but related types,
>>>>and how is it any safer?
>>
>>>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.
>>
>>Forget state machines. As soon as you have mutability, you have a
>>variable. Leave it at that.
>
> Nah, that doesn't suit me.
Fair enough. If you are only here to waste time, plonk! Received on Tue Jul 28 2009 - 15:20:23 CEST