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

Text File | 1992-12-12 | 3.2 KB | 75 lines

Newsgroups: comp.object
Path: sparky!uunet!newsflash.concordia.ca!grogono
From: [e-mail] (Peter Grogono)
Subject: Re: Object hidden state and side effects
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Nntp-Posting-Host: concour.cs.concordia.ca
Organization: Computer Science, Concordia University, Montreal, Quebec
References: <[e-mail]> <knight.724021213@cunews> <[e-mail]>
Date: Sat, 12 Dec 1992 18:10:59 GMT
Lines: 62

In article <[e-mail]> [e-mail] (Chuck Eaker) writes:
>In article <knight.724021213@cunews>, [e-mail] (Alan Knight) writes:
>
>|> In Smalltalk one cannot delete an object of any kind. One can,
>|> however, create numbers perfectly well.
>|>   Fraction numerator: 3 denominator: 4
>|>
>|> is perfectly valid Smalltalk code which creates a new fraction with
>|> value 3/4. Why is that crazy?
>
>It's crazy because it is not an example of creating a value. The
>value 3/4 has been around a long time. What this example creates
>is yet another digital representation of that value.
>
>It is more accurate to say that you have created space, and in
>that space will be placed a bit pattern which represents a value.
>But even that is a fiction. What is really created is not space
>but a way to refer to a space which can hold only one of many
>things each of which is taken to represent a value or even a range
>of values.
>
>In short, software must use objects to represent values. This is
>why the distinction between values and objects is of enormous
>importance. . . . . [stuff deleted]
>Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
>[e-mail]        [e-mail]       [phone]

I completely agree with Chuck's analysis, but I would like to
add my 2 bits' worth.

In thinking about, designing, and teaching OOLs, I have found it more
useful to distinguish "mutable objects" and "immutable objects"
rather than "objects" and "values". A class is immutable if all its
objects are immutable.

Integers, for example, are immutable. The interpretation of 2+3
is (!): "send message +3 to object 2, giving a new object 5."
If we allowed the object 3 to change into 5, there would be terrible
confusion -- as in FORTRAN.

It is better to regard literal constants, such as 57 and "wow",
as constructors with special syntax.

For the implementation, immutability allows optimization. It is
not necessary, for example, to create three new objects in order to
evaluate 57+57 (the three objects being "57", "57", and "104").
The reason that it is not necessary is that integers are immutable:
a programmer has no way of discovering that the two objects with
value "57" happen to share space or that the space is never even
allocated (except perhaps in a register).

Most languages treat integers, strings, and a few other basic classes
as special, largely because they are efficiently implemented by
hardware. (Peano arithmetic is not good for number crunching.)
The (im)mutable distinction, however, is orthogonal to implementation.
There is no reason why we should not, for example, declare matrices
to be immutable, if we could gain efficiency by so doing.

Peter