From: eaker@ukulele.crd.ge.com (Chuck Eaker)
Newsgroups: comp.object
Subject: Re: Object hidden state and side effects
Date: 14 Dec 92 17:54:02 GMT
Organization: GE Corporate R&D Center

In article <1992Dec13.152136.16852@hasler.ascom.ch>, steinman@hslrswi.hasler.ascom.ch (Jan Steinman - Bytesmiths, 3946) writes:
|> Oh, sorry for the misunderstanding. Will all C++ compilers that store the
|> value "3/4" in binary form *please* refrain from doing so? Instead, they
|> are to immediately begin using the *real* "3/4" that has been around a long
|> time.

The point is that computers cannot use "the *real* 3/4."

|> 
|> I don't see the difference between calling "3/4" an object or something else.
|> But let's make it more interesting; let's make it "2/3". In order to properly
|> and accurately represent that in C++, one will have to (oh no!) create an
|> object, since "2/3" has obviously not been around long enough for computer
|> makers to wire it into their architecture!

I'm sorry, but I'm afraid I don't see your point. Especially since I am
not aware of any binary representational scheme of real number values which
contains a bit pattern that exactly represents 2/3. Doesn't this show that
the representation is one thing and the value another? That fact that 3/4
can be represented exactly in such schemes does not show that those bit
patterns are identical to the value. There are many instances of those
bit patterns. There is only one instance of the value 3/4.

|> 
|> Chuck has simply mistaken one reality (the abstract notion of immutable value)
|> for another (what portion of immutable values computer manufacturers have
|> chosen to model in hardware).

My point is that the hardware things are models or representations, not
the values themselves.

|> 
|> >In short, software must use objects to represent values.
|> 
|> So far, so good, but...
|> 
|> >This is
|> >why the distinction between values and objects is of enormous
|> >importance. Software objects are used to model real world objects
|> >as well as real world values. Modeling objects with other objects
|> >is far more straight-forward than modeling values with objects.
|> >The field of numerical analysis is all about the difficulties
|> >which arise when one is forced to use objects to represent values.
|> 
|> Huh? Let's replace "object" (a loaded term in this context) with "thing". Let's
|> further agree that a fraction, or an integer, or the set of values "1", "2",
|> and "3", or for that matter, the set of values endorsed by the Republican
|> National Convention, are all "things". None of them *are* the set of binary
|> patterns that represent them in a computer's memory, but must be represented or
|> modelled since they are abstract. Some of them are modelled in hordware, some
|> must be modeled in software.

I have no problem with any of this.

|> If you accept this premise, do you still insist that it is fundamentally
|> necessary to represent "family values" in a different manner than the values
|> "1 2 3"?

Hmmm. I'm not sure I understand the question. If the question is
do I think things which are

  1. abstractions, thus
  2. immutable, and
  3. eternal (that they exist is tautologically true)

should be represented in a fundamentally different way from things
which are

  1. not abstract, hence
  3. have modifiable state, and
  4. can be created and destroyed,

then the answer is yes.

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.

|> ---
|> : : Jan Steinman, Bytesmiths			   steinman@hasler.ascom.ch : :
|> : : 2002 Parkside Court, West Linn, OR 97068-2767 USA	    +1 503 657 7703 : :
|> : : Beundenfeldstrasse 35, CH-3013, Bern, Switzerland	    +41 31 42 47 11 : :
|> 

-- 
Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
eaker@crd.ge.com        eaker@crdgw1.UUCP       (518) 387-5964