From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,82c7a4dae672250f X-Google-Attributes: gid103376,public From: dgibson@thalamus.cis.ohio-state.edu (david scott gibson) Subject: Re: "Object" types vs. "Value" types Date: 1996/03/21 Message-ID: <4is7s0INN1gp@thalamus.cis.ohio-state.edu> X-Deja-AN: 143603405 references: <4inn6f$1at@dayuc.dayton.saic.com> organization: The Ohio State University, Department of Computer and Information Science newsgroups: comp.lang.ada Date: 1996-03-21T00:00:00+00:00 List-Id: In article <4inn6f$1at@dayuc.dayton.saic.com>, John G. Volan 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