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

Internet Message Format | 1992-12-15 | 4.7 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: 15 Dec 92 22:45:36 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: eaker@ukulele (Chuck Eaker)
Organization: GE Corporate R&D Center
Lines: 88
Nntp-Posting-Host: ukulele.crd.ge.com

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"
or "levels of existence" or such things to become clear about what we
are doing.

|>
|> >My point is that the hardware things are models or representations, not
|> >the values themselves.
|>
|> What effects does this have on problem solving. I mean, other than the
|> notion that there is more than one binary represenation for any one
|> value?

It has a bearing on how we evaluate our models and solutions. If a value
can be changed in our system, the system is defective no matter what its
requirements are. An attribute set equal to 3 could suddenly turn out to be
equal to 5 despite the fact that the system did not assign a different
value to the attribute - the (now mutable) value just happened to change.
Unlike Fortran, our modeling tools and languages should not allow this
kind of thing.

|>
|> >Integer values are abstractions. So are family values. The values of
|> >good, ok, and bad are all abstractions, immutable and eternal.  Their
|> >representations should reflect these attributes.
|> >
|> >If marriages are represented with objects and the values of good and
|> >bad are applied to them according to a GOP or any other scheme, make
|> >sure that any instance of marriage can be created, destroyed, or
|> >modified, and that the value good is represented by a single object
|> >which cannot be created, destroyed, or modified.
|> >
|> >There is a fundamental difference between a data type and an object
|> >class that most languages fail to capture. All the representations of
|> >values represented by a data type are created (specified, etc.) when the
|> >data type is defined. This is not true of the instances of an object
|> >class. We know, in some sense, all the integers and all the colors.
|> >We do not know all the marriages.
|>
|> Oh no! Who told you the value "good" is eternal and immutable? I'm
|> almost sure that the very two of us have completly different
|> specifications of "good", and they are changing though time.

Immanual Kant told me. We may disagree about which things are good,
and our views of whether or not something is good may change over
time. But if we assign the value of good to a family value attribute
of a marriage, and if the value of good mutates to something else
(to be equal to the value bad, let's say) when we have not assigned
a different value to the family value attribute, we will have serious
doubts of the ability of our system to maintain the integrity of
the data we put into it. Things which are good may come and
go and may change from good to bad and back, but the value of good,
whatever its details are, is eternal and immutable.

|>
|> What do you mean by saying "We know in some sense [...]?" Why don't
|> we know all the marriages? Please elaborate.

As time passes, individual marriages come and go. If we had a
data base of the universe, there would be constant marriage
updates. But, we would not need to update the list of integers
or the list of colors unless we chose a bizarre way to represent
them or unless we chose, for efficiency reasons to not implement
all the integers and colors that actually exist. The color
green is eternal and immutable. Green things are not.
Representations of the color green are not.

|>
|> Hasko
|>
|> --
|> +-------------------------------------------------------+
|> | Hasko Heinecke @ Georg Heeg Objektorientierte Systeme |
|> | I _never_ mean what I say - and nobody else does...   |
|> +-------------------------------------------------------+

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