From: dave@alex.uchicago.edu (Dave Griffith)
Subject: Re: Object hidden state and side effects
Organization: University of Chicago
Date: Fri, 18 Dec 1992 15:28:23 GMT

In article <1992Dec17.163916.25512@kei.is.s.u-tokyo.ac.jp> jeff@is.s.u-tokyo.ac.jp writes:
>In article <1992Dec16.175126.14968@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) writes:
> >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?
>

Ooops, yes you're right.  For values copying _can_ be used, not _must_ be used.
Objects must be referenced.

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

That seems to be precisely where we part ways.  I don't think it is optimal
to say "tough" in this case.  We are describing a known limitation in current
language designs in which bugs can, and in my experience, do manifest.  
A limitation which _can_ be fixed with careful language design.  A limitation
which is particularly offensive to those who believe that the benefits 
of object orientation come from its ability to express data modelling with
minimal fuss.

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

It's not as easy as all that. Besides, I beat you to 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.

Eiffel, C++ and Objective-C, mostly.  I agree that there is a culture/
background problem.  Smalltalk, lacking any sort of even simple type 
constraints would certainly be a bad platform on which to define value/object
constraints.  The platform I had in mind really during all of this was
Eiffel (well really Rorschach, my language, but Eiffel is the closest out
there), which already supports a rich set of constraints, and for which
object/value constraints seem a pretty obvious extension.  (Certainly more
obvious than the expanded/non-expanded stuff that currently must be used
to implement values.) The Smalltalk worldview seems to be bound up with 
"Everything is an object", even such IMHO obvious non-objects like control
structures.  Of course you can map everything to objects, I just see few 
good reasons to do so.  

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

No problem here, I just think the _language_ should support it.  Data modelling
is one of the few things I feel should be that should be directly supported
by language constructs.  Not library, not comments, not coding standards,
language.  Perhaps thats being intrusive, I prefer to think of it as being
precise.

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

All else being equal, I agree.  But I'm already spending time designing a
language, so I might as well get it right.  My system of course _allows_ one
to implement values as objects and cross your fingers and hope no one misuses
it.  It simply also offers a better alternative.

>Arguing about what we call object and what we call value is pointless.
>

True, I pretty much think we've got that one nailed.
	

-- 
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       dave@alex.bsd.uchicago.edu
Become a sociopath.  We don't even have to sweat the big stuff.
Newsgroups: comp.object