NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/object/4605

Internet Message Format | 1992-12-21 | 4.0 KB

Path: sparky!uunet!noc.near.net!hri.com!spool.mu.edu!uwm.edu!linac!uchinews!alex!dave
From: [e-mail] (Dave Griffith)
Newsgroups: comp.object
Subject: Re: Object hidden state and side effects
Message-ID: <[e-mail]>
Date: 20 Dec 92 15:58:09 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (News System)
Organization: University of Chicago
Lines: 65

In article <[e-mail]> [e-mail] (Ralph Johnson) writes:
>
>In article <[e-mail]> [e-mail] writes:
>
>>I am really at a loss here.  What exactly (in concrete real terms) do
>>you expect people to do differently when using true for example once
>>it is recognized as a value and not an object?
>
>[e-mail] (Dave Griffith) writes:
>
>>Express their actual intent clearly and precisely, without requiring
>>unneccessary contortions to map their intent to a overly limitted language.
>>But I've always been a dreamer.
>
>This does not seem to me to be an answer "in concrete real terms".
>
>The difference between an "object" and a "value" seems to be that for
>a value, equality can be implemented by bit comparison of the things,
>while objects can only use identity of addresses in memory or else
>require a user-supplied function.  Isn't this just a result of immutability?

I've never said anything about bitwise comparison.  Equality on values might
certainly be user defined.  Even in these cases it should have restrictions,
e.g. it should be symmetric, reflexive, transitive, and substitutabilty of
equals for equals should hold in all cases.  Equality on objects would
be identity.  Identity of memory address might be an implementation of this,
although other implementations are certainly possible (think of distributed
and persistent environments).  Immutability of values is certainly necessary
for this to work.

>
>>But most languages have no way to _enforce_ the requirement that they "only
>>allow operations that are in line with their essential sameness".
>
>Most languages have no way to enforce anything that is interesting.
>We can't really enforce that a subclass provides the same behavior
>as a superclass.  In C++, I can enforce that a virtual function will
>return an integer, but not a positive integer (except by making a
>class for positive integers).  I can enforce that a sort function
>take a boolean valued binary function as a parameter, but not that
>it provide a total ordering on the collection to be sorted.  We need
>to improve the expressive power of our languages.  I think that trying
>to solve this problem just by making a value/object distinction is like
>applying a bandaid to someone who had a leg cut off.
>

This is a description of the current state of programming, when we were
discussing a perscription for possible future programming.  Actually it's not
even all that accurate, as it relies on some confusion as to the definition
of "enforce".  Eiffel (with the exclusion of a few egregious features like
"undefine") can and does enforce that a subclass has the same behavior as
a superclass.  Of course, it does this at runtime (solving these problems
at compile time is undecidable), and it only does so with behaviour that
the programmer specifically asserts (pre- and postconditions, class invariants).
If the behaviour is different, a runtime exception is thrown.  Not perfect,
but probably the best that the halting problem will allow.  The positive
integer example is enforce in the same way by Ada, of all things.  In any
case, the value/object distinction is certainly compile-time enforcable.
As others in the discussion have pointed out, they do enforce the distinction
by hand.

--
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       [e-mail]
Become a sociopath.  We don't even have to sweat the big stuff.