Re: "Object" types vs. "Value" types

[dgibson@thalamus.cis.ohio-state.edu (david scott gibson)]

In article <4inn6f$1at@dayuc.dayton.saic.com>,
John G. Volan  <John_Volan@ccmail.dayton.saic.com> wrote:

>In light of these notions, I long ago came to the conclusion that, as
>far as programming was concerned, there was a useful distinction to be
>made between two sorts of data types: "object" types and "value"
>types. An "object" type is a data type for which the distinction
>between "identity" and "state" was strong, whereas a "value" type would
>lack this strong distinction.

An interesting post!  I follow and agree with you most of the way, but
I'm a bit confused with your notion of "value types".  (I digress a bit
before getting to that :-).

>Assignment just doesn't make sense for an "object" type.  You shouldn't
>be able to just "copy" an object willy-nilly -- what would that mean?
>Oh, you could copy the _state_ of that object into another object
>(write yourself a Copy procedure). Or you could copy the _identity_
>('Access) of that object from one (access) variable to another (access)
>variable.  But copy the "object" per se?  No, I'd rather shut off
>assignment rather than open up that can of worms.  Physical objects in
>the real world don't go around being indiscriminately replicated 

Copying the abstract value (or state) of an object seems to require
creating a _new_ object which has the same abstract value as the
original object (although it may have a different concrete
representation).  For scalar types and simple aggregates of scalar
types, the effect of an assignment (:= with no Adjust) generally
corresponds to this behavior.  The old value of the target variable is
destroyed and is replaced by a copy of the source's value. This, in
essence, creates a new object identified by the target variable with
the same abstract value as the old object identified by the source
variable.  The total number of objects (as reflected by the number of
variables) is conserved.  Due partly to the simple one-to-one
correspondence between abstract values and concrete representations,
assignment provides the desired behavior in many cases.  If aliasing
is allowed, however, all bets are off and reasoning about the
resultant software becomes extremely difficult.

So how can you move around non-trivial objects for use in operations
without introducing aliasing?  Use swapping!  The Swap operation
exchanges the abstract values of two objects of any kind.  Swap can
always be implemented for a minimal constant cost and its use
maintains a conservation of objects which works well for modeling many
real world systems.  Copying, which might be implemented by :=
augmented with an appropriate Adjust, is often unnecessary, expensive,
and, cannot always be implemented (although the latter not often a
practical limitation).  For more info on swapping check out references
under: http://www.cis.ohio-state.edu:80/hypertext/rsrg/RSRG.html.

>On the other hand, if you do have a data abstraction for which
>assignment makes sense, that's okay too, you can make it non-limited --
>I just wouldn't call that an "object" type, I'd call it a "value" type.

What's an example of a true abstraction where "assignment" does make
sense?  It's not clear to me what you mean by a "value type".  Do you
consider the Ada type Integer a value type?  That's not an
abstraction, however, that's a representation.  The mathematical
integer type is an abstraction.  

>Note that there's nothing about this notion of "value" types that
>precludes such "object-oriented" concepts as "inheritance" and
>"polymorphism" and "type extension" and "dynamic dispatching."  I think
>it's perfectly reasonable to talk about having classes of "value"
>types, with derived value types inheriting attributes and behavior from
>ancestor value types, and adding new attributes and behavior, and so
>forth.  "Value" classes can work just like "object" classes -- the only
>difference is that assignment is defined for the former but shut off
>for the latter.

I'm not following this.  I don't understand your notion of "value
classes".

>"object-oriented" is a misnomer.  The paradigm that everybody is so
>gung-ho about these days should have been called "*CLASS*-oriented"
>programming.  A programming language could hypothetically give you
>_objects_ without necessarily giving you _classes_ as well.

Sure.  I consider good old Ada83 ADT-style programming to be
programming with objects.

>is just private implementation details anyway.  The bottom line is that
>if you want assignment to be meaningful for your data abstraction, then
>the publicly-visible semantics of your abstraction have to be totally
>stripped of any notion of unique identity.  

I'm not convinced that the assignment operation has a useful role in a
programming style which attempts to convey an abstract (human
understandable) model of a system.

>Contrast this with a limited "object" type:  You won't be able to use
>assignment to copy an "object" to multiple locations, although you
>might make multiple copies of an _access value_ that "identifies" that
>object. 

Use of pointers is embedded in the current state of practice, but it
makes formal reasoning about the code extremely difficult.
Correspondingly, visible use of pointers tends to make maintenance
extremely as difficult.  The RESOLVE language and discipline prohibits
aliasing in any form.  RESOLVE encapsulates much pointer functionality
in an "interesting" component called Chain_Position.  In RESOLVE/Ada,
access types types are only used in certain foundational components
upon which most components are built.  (See reference mentioned above
if you're curious.  BTW, RESOLVE/Ada95 should be out later this year.)

>Now, as for a particular abstract data type, such as our moldy old
>friend, the stack:  Is a stack an "object"?  Or is it a "value"?
>It can be _either_, depending on how you choose to perceive it.  I
>believe most folks would tend to view a stack as an "object" (and
>that's how I tend to view it myself), on the grounds that the Push and
>Pop operations are thought of as having "side-effects."  However, I
>admit that one might reasonably argue for a view that interprets a
>stack as a "value," by analogy with another "aggregate" abstraction:
>the array.

This seems like a purely concrete-level analogy.  Again I'm failing
so see why you would want to view a stack in this way.

>I even reflect that philosophy in my chosen naming style:  I tend to let
>the package name carry the sense of an abstraction, and I use some
>"nondescript" identifier for the type encapsulated in the package, on
>the grounds that everybody should refer to it as "Package.Type" anyway.

This sounds reasonable, but with long descriptive package names and
perhaps nested units, the dotted notation might get a bit unwieldy. 

Dave
--
dgibson@cis.ohio-state.edu