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

Text File | 1992-12-17 | 4.8 KB | 88 lines

Newsgroups: comp.object
Path: sparky!uunet!europa.asd.contel.com!emory!swrinde!sdd.hp.com!spool.mu.edu!uwm.edu!linac!uchinews!alex!dave
From: [e-mail] (Dave Griffith)
Subject: Re: Object hidden state and side effects
Message-ID: <[e-mail]>
Sender: [e-mail] (News System)
Organization: University of Chicago
References: <[e-mail]> <[e-mail]> <knight.724557211@cunews>
Date: Thu, 17 Dec 1992 03:35:22 GMT
Lines: 76

In article <knight.724557211@cunews> [e-mail] (Alan Knight) writes:
>In <[e-mail]> [e-mail] (Dave Griffith) writes:
>
>>In article <[e-mail]> [e-mail] writes:
>>>In article <[e-mail]> [e-mail] (Dave Griffith) writes:
>
>> ... "Objects" as I have
>>been using the term use reference semantics.  Two objects are only equal if
>>they are identical.  "Values" use copy semantics for assignment. (What they
>>use for equality semantics is a deeper and IMHO more interesting question, but
>>I digress.)  How these semantics are actually implemented is a implementation
>>decision and should not be considered here.
>
>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.

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.

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.

>>>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...)

--
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       [e-mail]
Oh, by the way, I almost forgot.  Godot called.  He said he'd be late.