NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/object/4614

Text File | 1992-12-21 | 5.4 KB | 125 lines

Newsgroups: comp.object
Path: sparky!uunet!uchinews!alex!dave
From: [e-mail] (Dave Griffith)
Subject: Re: Object hidden state and side effects
Message-ID: <[e-mail]>
Sender: [e-mail] (News System)
Organization: University of Chicago
References: <knight.724800436@cunews> <[e-mail]> <knight.724904387@cunews>
Date: Mon, 21 Dec 1992 14:48:48 GMT
Lines: 113

In article <knight.724904387@cunews> [e-mail] (Alan Knight) writes:
>In <[e-mail]> [e-mail] (Dave Griffith) writes:
>
>>In article <knight.724800436@cunews> [e-mail] (Alan Knight) writes:
>
>
>>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.
>

My problem is sadly that I've done too much work in other areas, namely
defining the semantics of interobject relations.  At some low level, relations
have to be worked with as sets of tuples.  Sets is the key word here, as
it's kind of difficult to work reasonably with sets without a strong
equality operation.  Weak set theories without such an equality do exist,
but it becomes almost impossible to specify useful work in them.  Frankly
the payoff from direct support for interobject relations seemed to more
than make up for the sacrafice of restricted equality.  Perhaps your right,
and I've just talked myself into my position.

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

Certainly the pure functional languages provide no such operation, as it
would completely trash referential transparency.  ML might get away with it.

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

Hmmm, maybe we haven't been talking about the same thing after all.
In the first case, there is no object or value that is having it's state
altered.  A variable, i, is being successively bound to different values.
Variables are certainly not in any way what I was speaking of when I
spoke of objects.  In the second case, counters are certainly reasonable
objects.  I realize that to do identity checking of compound objects in C you
first must get a reference to them. This seems a minor syntactic bug in
C, much like requiring dynamic function calls to use pointer syntax.  The
semantics of object identity are there, however.

On the other hand, you and Ralph Johnson have given me a few quite good
examples to think about.  I had simply forgotten IEEE float when trying to
come up with good non-reflexive equality example.  Interval arithmetic
struck me as an example of a kind of thing (we're running out of words)
without a good equality operation.  Here I was having such fun doing
compiler optimizations and now I have to go back to the language semantics...


--
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       [e-mail]
A man's best friend is his dogma.