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

Internet Message Format | 1992-12-16 | 4.8 KB

Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!ukulele!eaker
From: [e-mail] (Chuck Eaker)
Newsgroups: comp.object
Subject: Re: Object hidden state and side effects
Message-ID: <[e-mail]>
Date: 17 Dec 92 00:10:46 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: eaker@ukulele (Chuck Eaker)
Organization: GE Corporate R&D Center
Lines: 84
Nntp-Posting-Host: ukulele.crd.ge.com

In article <[e-mail]>, [e-mail] (Peter Grogono) writes:
|> In article <[e-mail]> [e-mail] (Chuck Eaker) writes:
|> >In article <[e-mail]>, [e-mail] (Hasko Heinecke) writes:
|> >|> In article <[e-mail]> [e-mail] (Chuck Eaker) writes:
|> >|> >The point is that computers cannot use "the *real* 3/4."
|> >|>
|> >|> You wanted philosophy, so here it is: What *is* the real 3/4. What would
|> >|> Immanuel Kant say?
|> >
|> >I'm sure Kant and other philosophers would agree that 3/4 is a rational
|> >number, and that whatever the nature of its existence, there is only
|> >one such number, it cannot be created, destroyed, copied, or changed
|> >in any way. Unlike philosophers, we don't have to worry about "realms"
|> > ............
|>
|> I suggest we all go and re-read \cite{Whitehead:1910} and then resume
|> the conversation.
|>
|> @book{Whitehead:1910
|>          author = "A.N. Whitehead and B. Russell",
|>          title = "Principia Mathematica",
|>          publisher = "Cambridge University Press",
|>          date = "1910--13"}
|>
|> Peter

I'd rather just summerize from memory: the symbol "2", for example,
denotes the class of all couples. And that's about all in those
three volumes that strikes me as being relevant to the discussion.
Other plausible interpretations are that "2" denotes a point on the
number line. But whatever theory (interpretation) you choose, it
had better have as a consequence that the denoted thing is unique
and can't be created or destroyed, etc. And all of this is true of
the class of all couples just as it is true of the class of all
zero-tuples (the null class).

What's the point of all this? We populate our applications with
"ordinary objects" which are things that come and go and whose
attributes take on different values during the life of the
application. Unfortunately, we are forced to use the same ordinary
object construction mechanism to model domains of values. The
potential danger in this "optimization" (or re-use, perhaps) is
that our application could well end up incorrectly modeling
whatever its domain is in dangerous ways.

Here is a simple example. Suppose we have a Thing class which has
an attribute, call it imbalance, and its current value must be from
the domain of imaginary numbers. If we implement this domain as
instances of a class that we create on the fly as needed, we could
well have multiple instances of the same imaginary number around.
Thus, it is possible to confuse tests for identity with tests for
equality.  But ordinary people don't think of this as being
possible with imaginary numbers because two imaginary numbers are
identical iff they are equal. Unlike our implementation, the
statement 1+2i = 1+2i has a single meaning. Consequently, they
never think to protect themselves against these possibilities which
only arise because of our inappropriate implementation of a value
domain.

Very good object-oriented developers do understand all of this.
They are very careful to build value domain classes so that invalid
operations can't be performed on them (provided people use them as
advertised). But in my experience, many of the really nasty
problems with complex object-oriented systems have been the result
of not being able to completely maintain and cover up the "big
lie": that an ordinary class mechanism is being used to implement a
value domain which means that certain kinds of inappropriate
operations can, and were, performed on values. (I suspect that
the big lie may be behind most memory leaks.)

So, I don't think it is a good idea to pretend that a value is an
object even though we generally get away with it. Furthermore, it
strikes me as most peculiar to say: "Sending the message +2 to the
object 3 yields the new number 5." Yet our tools encourage us to
talk this way. I'm not convinced that this is helping us push the
level of abstraction at which we work closer to that of application
domains. Application domain people don't talk like this at all.
Send messages to objects, not to values.  The ideal tool would
allow us to implement value domains without these risks and without
having to speak in convoluted ways.

--
Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
[e-mail]        [e-mail]       [phone]