From: jeff@is.s.u-tokyo.ac.jp (Jeff McAffer)
Newsgroups: comp.object
Subject: Re: Object hidden state and side effects
Date: 17 Dec 92 16:39:13 GMT
    <1992Dec15.014420.6604@midway.uchicago.edu> 
    <1992Dec16.65250.10645@kei.is.s.u-tokyo.ac.jp> 
    <1992Dec16.175126.14968@midway.uchicago.edu>
Reply-To: jeff@is.s.u-tokyo.ac.jp
Organization: University of Tokyo, tcejorP Project.

In article <1992Dec16.175126.14968@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) writes:

 >You deleted the modelling stuff, which provided the semantic background, and 
 >ignored all but the first two sentences of the stuff that you did quote. 

Deleted but not ignored.

 >Actually, the distinction between copy semantics and reference semantics is 
 >_not_ an implementation detail.  It is a central part of the design of
 >any language which has assignment or procedure call.  "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.  

Yikes!  Just when I thought we were agreeing.  I was always thinking
that values were immutable.  If so, why would you copy them rather
than just point to the defining instance?

If I get it right here I think you are talking about "values" really
representing/indicating/whatever, concepts like true, false, 2...  In
which case they can be impelemented many different ways to the same
effect.  What I don't see is your problem with doing that with
objects.  Just implement different objects with the behaviour you
want.  Presto.  Publish be behaviour, if people use it wrong well,
tough.  Of course, some tools might be nice but personally I see this
much more as a specification problem than an OOP or language problem.

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

I'll make you a deal.  You give me a way to describe essential
sameness and I will implement a language that enforces it.

I am detecting a bit of a cultural/background problem here.  Dave
Griffith, correct me if I am wrong (wouldn't be the first time), but
you've been using C++ (or similar languages) (gee, is C++ a value?)
right?  Nothing wrong with that but I find that it gives a different
point of view on things.  (I'm pretty much a Smalltalker) It [C++]
really allows many more of the types of problems that you talk about.
I do not want to start a discussion about C++.  Just my observations.
Discount them if you will.

I try to be non-intrusive in people's programming styles.  If I build
a new class, I spec it and give it to people to use.  I say how it is
intended to be used, under what conditions it is likely to fail and
generally try not to reveal implementation detail.  I think that this
eliminates many of your complaints.

I do agree that a *system* which supports this sort of *spec* in a
real way would be very beneficial in many ways (optimization, error
checking...).  I doubt that it necessitates new programming languages
or the definition of special things called values aas distinct from
objects which have some particluar behaviour characteristics.  It is
the spec that we are after here.  How to describe these things.
Arguing about what we call object and what we call value is pointless.

--
--
ato de, |m        -- Santa or Satan?  Think about it.
Newsgroups: comp.object