From: knight@mrco.carleton.ca (Alan Knight)
Subject: Re: Object hidden state and side effects
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: Carleton University
Date: Mon, 21 Dec 1992 02:19:47 GMT

In <1992Dec20.162050.14652@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) writes:

>In article <knight.724800436@cunews> knight@mrco.carleton.ca (Alan Knight) writes:

>>[Misattributes my stuff to Ben Bongalon, but I'll cope.]

Sorry.

>>As far as the particular question of objects and values is concerned,
>>there are really two separate issues which I think are orthogonal: the
>>presence of an identity operation separate from equality and
>>mutability. We get four classes of things, which I'm going to call by
>>the names that have been used in this discussion, even if I don't
>>think they're entirely appropriate.
>>

>The problem is just what your expecting equality to do.  If it's just
>another comparison, then all of the following make sense.   If you also
>expect equality to satisfy "substituting equals for equals gives equals",
>things get more difficult.  In that case, mutable objects pretty much must
>have equality as identity.

I don't believe this. While it is certainly possible for the
programmer to define equality operations that do not satisfy such
constraints, all that means is that one must either trust the
programmer or have a mechanism to enforce the constraints.  I cannot
accept that I am not allowed to use strcmp or even strcasecmp as the
equality operation for my mutable string class. 

Furthermore, the axioms you define for equality fall down for a large
class of reasonable values (let alone objects) such as approximations
for floating point numbers (e.g. interval arithmetic). The fact that
they fall down for these type of objects/values/whatever makes
programming with them difficult, but that doesn't mean people don't
want to use them.

You seem to be willing to do a lot of work in some areas, but just
dismiss others as too difficult without much thought.

>>Mutable objects: Have an identity operation, can be modified.
>>The default case of objects.
>>
>>Immutable objects: Have no operations which modify state, but have an
>>identity operation. e.g. non-mutable strings

>Might be useful, although the need for an identity operation for non-mutable
>strings escapes me.

For mutable strings you are willing to make identity the only equality
operation, but you can't see a reason for using it at all on
non-mutable strings?  I personally don't use identity operations much
except as an efficiency hack, but it can be quite valuable there.
Don't functional languages provide an identity operation? Certainly
LISP does. Maybe we should ask a functional programmer.

>>Values: Have no operations which modify state, have no identity
>>operation. e.g. numbers
>>
>>Normal storage (or mutable values): State can be modified, but there
>>is no identity operation. e.g. storage allocated on the stack in
>>traditional languages. 

>'Splain me, boss.  I'm feeling dumber than usual.

Think of a "normal" procedural language, e.g. C.

int i;
i=0;
i++;

I have just modified the internal state of i. If you don't believe that, try 

struct counter {
  int i;
}
counter j;
j.i++

(apologies for poor C syntax) I can modify the internal state of a
counter, but there is no meaningful identity operation for
stack-allocated counters.  The best I can do is to take pointers to
them and compare those for identity, but I submit that identity of
references is something different from identity of the things
themselves.

-- 
 Alan Knight  knight@mrco.carleton.ca  +1 613 788 2600x1027 
 Dept. of Mechanical and Aerospace Engineering              
 Carleton University, Ottawa, Ontario, Canada, K1S 5B6      

Newsgroups: comp.object