From: knight@mrco.carleton.ca (Alan Knight)
Subject: Re: Object hidden state and side effects
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: Carleton University
Date: Fri, 18 Dec 1992 01:46:40 GMT

In <1992Dec17.033522.2857@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) writes:

>In article <knight.724557211@cunews> knight@mrco.carleton.ca (Alan Knight) writes:
>>This definitely seems to be the root of the confusion. You mean
>>something different by "object" than I do, and I expect than Jeff
>>McAffer or Jan Steinman do.  If you call something an object only if
>>equality and identity are the same operation, then most OO langauges
>>already support the distinction being called for, since the equality
>>operation can be defined to be anything you like. This is certainly
>>the case for "value objects" in Smalltalk, such as Booleans, Numbers,
>>Symbols, etc. Somebody just posted that the same thing is true in
>>Eiffel. Maybe you can't do it in C++, but that's a whole other debate.
>>

>It most certainly is not true for Eiffel.  Eiffel goes to great lengths
>to make a distinction between reference and copy semantics, so that they
>can be pretty arbitrarily mixed and matched line by line throughout the
>code.  There is no enforced concept of immutability. There may be uses for 
>this sort of thing, including implementation of values, but it is most 
>definitely not a direct, enforced way of declaring a value.

I didn't say there was an enforced concept of immutability. You can
make an object immutable by not declaring any destructive operations
for it. 

>Redefining the equality operation is useful, but again is not all that is 
>necessary for the concept "value".  One must also have immutability.

>As for Smalltalk, you've just listed a bunch of system-declared values.
>We are talking about user declared values.  Anyone can hack special cases
>into their system-defined libraries.  Certainly it is done in all of the 
>languages you've mentioned here.

There is no difference. In Smalltalk the only really special cases are
SmallInteger, True and False. True and False can be implemented as
non-special cases, but the performance penalty is so high as to be
prohibitive. Strings, large integers, fractions, meta-numbers, points,
and many others are all implemented as user declared values. By that I
mean that their source code is written in Smalltalk and freely
modifiable by the user. Depending on the implementation, some of the
operations might be written as C/FORTRAN/whatever primitives, but that
mechanism is also available to the user, and doesn't change the
mutability/immutability or identity/lack thereof. It only makes the
operations faster.

>In any case, you quoted me out of context.  It certainly isn't the case
>that the only distinction between objects and values is assignment semantics.
>It is just one of the distinctions.

But I don't think it's true. I have implemented many objects where
equality is not the same as identity.

>>>>about it.  They are just objects to which I can send messages, pass as
>>>>parameters...  They have a protocol... and allow only those operations
>>>>that are in line with their "essential sameness"
>>
>>>But most languages have no way to _enforce_ the requirement that they "only
>>>allow operations that are in line with their essential sameness".  They
>>>treat their builtin classes as "special", and don't allow programmer defined
>>>classes to be defined as special in the same way.  It would be useful in C++
>>>for instance to define a Bignum class which didn't allow the programmer
>>>to set 3 equal to 5, even if that Bignum class is eventually subclassed.  
>>>Subclassing can blow away the original programmers intent of immutability, 
>>>with possibly disastrous effects on program correctness.
>>
>>The only "special" distinction in Smalltalk is between SmallIntegers
>>and everything else.  The distinction is effectively invisible in
>>normal use.  Also, what you are asking for is possible in C++ (but not
>>in Smalltalk). In C++, private class members are not visible to
>>subclasses. If you don't provide any destructive functions then they
>>cannot be added when you subclass. I think you can circumvent this by
>>writing "friend" functions, but that's an explicit mechanism provided
>>to circumvent the language restrictions in the name of performance.
>>

>Close, but not quite.  Invisible certainly implies immutable (you can't 
>change what you can't see), but the converse fails.  C++ (unless Bjarne has
>changed it yet again) does not provide a way of making an instance variable
>visible but immutable.  (Of course, any C derived language is going to have
>extreme problems with immutability anyway...)

One can provide a function which returns the "value" of something in
the internal state.  This does not allow the internal state to be
modified unless the thing returned has itself reference semantics, but
makes the variable effectively visible.  I would consider it bad form
to access a variable directly outside the class. 
-- 
 Alan Knight  knight@mrco.carleton.ca  +1 613 788 2600x1027 
 Dept. of Mechanical and Aerospace Engineering              
 Carleton University, Ottawa, Ontario, Canada, K1S 5B6      

Newsgroups: comp.object