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: Sat, 19 Dec 1992 21:27:16 GMT

>In article <BzF6uA.1u3@inews.Intel.COM> bongalon@tcad05.intel.com (Ben Bongalon) writes:
>>

>Seems to me like we've gone around enough to realize that we're all finally
>talking about the same thing, just from different views.  Now that we've
>got our respective terminologies agreeing, I feel like it's time for a 
>blatant try at closing the discussion.

>Values can be indirectly implemented as objects. The only benefit of this 
>(and yes, it's a large one) is that languages do not require two separate 
>semantic constructs for two somewhat related mental constructs.  The direct 
>costs of this is that in current languages this implementation is not quite 
>safe, and requires unenforced coding restrictions to ensure that values really 
>act as values.  This is a known bug source, and should be approached as one.  
>A possible indirect cost is that it places one further interpretation step
>between a programmer's design and her implementation. As decreasing the 
>design/implementation distance is one of object oriented programming main
>strengths, this should be considered accordingly.  Given these costs and
>benefits, I believe that a language could fruitfully be designed which supports
>values and objects as separate concepts.  The costs and benefits probably don't
>justify writing a new language to specifically test this hypothesis, and 
>certainly don't justify increasing the complexity of already overly complex
>languages (C++, Eiffel, and Ada in particular).  But if you just happen to find
>yourself designing a new language which uses some OO concepts and extends
>them with other semantic modelling capabilities (relations, in my case), then
>it's probably worth trying them out.  If it pays off, it's part of the 
>benefits of breaking new ground.  

I can agree with most of this, but of course I have to add my two cents. 

I agree entirely with Ralph Johnson that adding just the ability to
distinguish values and objects is completely inadequate, and that a
more comprehensive approach to describing code semantics is required.
Given that you seem to be attempting to design a next-generation
language, by all means explore this.

As far as the particular question of objects and values is concerned,
there are really two separate issues which I think are orthogonal: the
presence of an identity operation separate from equality and
mutability. We get four classes of things, which I'm going to call by
the names that have been used in this discussion, even if I don't
think they're entirely appropriate.

Mutable objects: Have an identity operation, can be modified.
The default case of objects.

Immutable objects: Have no operations which modify state, but have an
identity operation. e.g. non-mutable strings

Values: Have no operations which modify state, have no identity
operation. e.g. numbers

Normal storage (or mutable values): State can be modified, but there
is no identity operation. e.g. storage allocated on the stack in
traditional languages. 

I think it is better not to have an identity operation at all for
things for which it doesn't make sense. The alternative would be to
have an identity operation which just calls the equality test, but I
don't think this is as good.

Normal object-oriented languages (by which I mean Smalltalk, since
it's what I use normally :-)) can handle objects and immutable objects
(barring cheating with the reflective facilities). It cannot handle
removing the identity operation, particularly since it cheats on this
operation (does not really send a message). This is probably worth
looking at if you are designing a new language. I wonder if Self would
be able to do this...

For all of these, the equality operation must be user-defined
(contrary to somebody's earlier assertion that objects use identity
for equality).  Equality can be quite a complex operation. For
example, under IEEE standard arithmetic, there are floating point
numbers which are represented by identical bits, but are not equal
(Nan).


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