moss@takahe.cs.umass.edu (Eliot &) (02/01/90)
I want to make a brief follow up comment regarding mutability and identity. Identity has to do with equality -- that is, two objects are considered the same (identical) if they are "equal". Under this view one must distinguish equality of *objects* (identities) from equality of *states of objects* (roughly, values of the "variables" contained in the objects). This is true only for mutable objects, though -- the states can be equal for two distinct objects. *Immutable* objects should act like pure mathematical values (even if they don't fit into a small number of bits), and distinct copies of them *should not* be distinguished. (Almost) every mutable type (class, abstract data type) also has an immutable version, where each mutating operation of the mutable type instead produces a new immutable value without changing any of its inputs. Further, both can be useful to have around. In sum, the identity of an *immutable* object *is* its (abstract) value. Testing identity may not be entirely trivial, though -- consider the case of immutable sets using an array of unordered, possibly duplicated, elements as the representation. To test if immutable set X is the same as immutable set Y, we must check that each element of X occurs in Y and vice versa (this is expedited by removing duplicates and sorting, though sorting is not always possible since not all element classes have reasonable total orders defined on them). Manipulating the identity of the *mutable object representing* an immutable object will generally be a violation of clean semantics. (However, it would seem perhaps reasonable when comparing two immutable sets X and Y to first check whether their representing objects are identical, in which case the sets are clearly identical as well.) Likewise, it would be semantically improper to mutate the representing object in such a way as to change which abstract value is represented. (That is, it is fair to re-order and remove duplicates from the array representing an unordered immutable set, since that does not change what set is represented, but removing all occurrences of an element would be improper.) Another point to keep in mind is that an object/class can be immutable and yet *refer to* mutable objects. For example, consider an immutable set of airline reservation records. The individual records might still be mutable, but the *set* is immutable -- its state is the *identities* of the records in the set, not their *states*. (Of course, one might want sets of record states (snapshots), too, but that is a different abstraction.) One must be especially careful with collections (not meaning the Smalltalk class, but every abstract data types that is essentially a collection (more or less structured) of other, independent objects) not to get tangles up about mutability. Regarding identity, it is only the strongest (most distinguishing) equivalence relation defined over objects of a class. In general there are weaker equivalence relations of interest (e.g., mutable objects that currently have the same state, but may not be identical; arrays that contain the same elements at the moment, but possibly in different orders, etc.). A final note -- none of this stuff is directly related to inheritance. We thought through many of the issues in designing CLU, a language supporting abstract data types but not inheritance, in the early 70s. Cheers! Eliot -- J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206; Moss@cs.umass.edu
sakkinen@tukki.jyu.fi (Markku Sakkinen) (02/02/90)
I think this _is_ interesting. However, if this discussion becomes too dogmatic for most followers of the newsgroup, we might move it offline. In article <1990Jan31.052750.22507@Neon.Stanford.EDU> pallas@Neon.Stanford.EDU (Joe Pallas) writes: >A while ago we had some discussion about whether certain objects in >Smalltalk were ``first-class.'' It's taken me a while to organize my >thoughts on this, but I think there's still something to be gained by >further discussion. The focus here is on SmallIntegers. > >In article <2740@tukki.jyu.fi>, Markku Sakkinen wrote: > ... > Regarding Booleans, the fact that True and False need to be singleton > subclasses is an ugly wart that in my opinion shows a flaw in the > Smalltalk philosophy. > >I think this is an unusual view. Most people complain about the fact >that one-of-kind objects still need classes, but I've rarely heard >complaints about the existence of one-of-a-kind objects. In any >event, we have two interpretations that avoid one-of-a-kind objects. I did not want to complain about one-of-a-kind objects in general, but I think the Boolean values are "two-of-a-kind". One further thing in Smalltalk-80 that looks less than elegant to me really is the need for every class to have a metaclass of its own. > [claim by me that SmallIntegers are never created nor deleted, > conceptually] >I respectfully disagree here. There is nothing I can find in the >language definition that requires SmallIntegers to be unique. These >two views are equally valid. If one cannot _find_ some thing in the Smalltalk-80 bible, that's no guarantee that it isn't hidden there somewhere :-) I remember having read that even Symbols are guaranteed to be unique. You are right in that these viewpoints yield the same result: 1. SmallInteger objects are created and deleted as needed, but they cannot be compared by identity, only by value. 2. For each small integer value there is exactly one conceptual SmallInteger object, but it can be more expediently be referred to by value (and a tag bit that distinguishes this value from a reference). I only think that Smalltalk-80 prefers the latter viewpoint. > ... > illuminating classic, "Object Identity" by Khoshafian and Copeland > (ACM OOPSLA'86 Proceedings). > >This is an excellent paper, yes, but it neglects one point---namely, >why test identity? I claim there is only one reason to compare the >identity of two objects: to determine whether they can take on >different values. For immutable objects, identity tests are >pointless (except to do magic, as shown below). It does not neglect the point, because there is no such thing as an immutable object in the model of that paper. There is the crucial difference from the Smalltalk model that atoms are _values_, not objects, but there are also objects of atomic types - they are mutable. (You probably guessed which model I consider more logical.) I agree that one can rather well substitute equality for identity when comparing immutable objects. Of course, in the general case when they are not necessarily atomic, this holds only for "deep-immutable" or "transitively immutable" objects. (At least CLU defines non-atomic immutable objects, which may still point to mutable objects.) >Anyway, let's look at > > Three Interpretations of > SmallIntegers > >Considering mutability, uniqueness, equality, and ``degree of magic''. > ... That was nice. However, the very fact that you needed "a bit of magic" in all three interpretations reinforces my opinion that there is a fundamental glitch in the model. As far as I can see, Khoshafian and Copeland don't need any magic to interpret _their_ model. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland
wesommer@athena.mit.edu (Bill Sommerfeld) (02/05/90)
"Two things are `equal' if they're the same color". "Two things are `eq' if, when you paint one, the other changes color." - Gerry Sussman, explaining the difference between "eq" and "equal" in LISP. -- Henry Spencer is so much of a | Bill Sommerfeld at MIT/Project Athena minimalist that I often forget | sommerfeld@mit.edu he's there - anonymous |
sakkinen@tukki.jyu.fi (Markku Sakkinen) (02/05/90)
In article <MOSS.90Feb1095903@takahe.cs.umass.edu> Moss@cs.umass.edu writes: >I want to make a brief follow up comment regarding mutability and identity. > ... >objects. *Immutable* objects should act like pure mathematical values (even if >they don't fit into a small number of bits), and distinct copies of them >*should not* be distinguished. (Almost) every mutable type (class, abstract >data type) also has an immutable version, where each mutating operation of the >mutable type instead produces a new immutable value without changing any of >its inputs. Further, both can be useful to have around. In sum, the identity >of an *immutable* object *is* its (abstract) value. Testing identity may not > ... There is a lot of sense there. However, I would say that one *can* regard immutable objects as abstract values (with the provision below), but one is not forced to. For instance, it could be a sensible operation to "freeze" an originally mutable object to immutability: should it lose its identity then? > >Another point to keep in mind is that an object/class can be immutable and yet >*refer to* mutable objects. For example, consider an immutable set of airline > ... >(snapshots), too, but that is a different abstraction.) One must be especially >careful with collections (not meaning the Smalltalk class, but every abstract >data types that is essentially a collection (more or less structured) of >other, independent objects) not to get tangles up about mutability. > ... Right. My point of view is that an immutable object that (directly or indirectly) refers to some mutable object cannot be considered an abstract value. In a draft paper, I suggest the term 'totally immutable' for objects that can - the definition should be pretty obvious. > >A final note -- none of this stuff is directly related to inheritance. We >thought through many of the issues in designing CLU, a language supporting >abstract data types but not inheritance, in the early 70s. One should certainly not stop learning from languages like CLU and Ada just because they are not "object-oriented". Although CLU has the same flaw (in my opinion) as Smalltalk that it does not allow mutable objects of atomic types, it is more orthogonal than Smalltalk by allowing immutable constructed types. However, I would like to consider mutability not as an aspect of _type_, but independent of it. That's the way "conventional" programming languages usually treat it, only they may not always have syntax for expressing constants of arbitrarily complex types. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland
gza@mentor.cc.purdue.edu (William R Burdick) (02/05/90)
I didn't catch the whole discussion on this: In article <1990Jan31.052750.22507@Neon.Stanford.EDU>, Joe Pallas wrote: In article <2740@tukki.jyu.fi>, Markku Sakkinen wrote: Regarding Booleans, the fact that True and False need to be singleton subclasses is an ugly wart that in my opinion shows a flaw in the Smalltalk philosophy. but, it seems to me that if you look in the class hierarchy in Smalltalk, you'll find a class called 'Behavior.' This is because a class is simply a definition of how an object behaves. So if you want to provide two objects which you deem to have sufficiently different behavior, you should make different classes for them. True and False don't *need* to be singleton subclasses; the folks at PARC could as well have written a primitive which looked at the value of the receiver and then did the if-thing -- but what's the point of that? I don't see having singleton subclasses as a wart or a flaw, it's just a different approach than other people might have, but equally valid. It's obvious that true objects behave differently from false objects. A valid approach to modeling the behavior is to make two different classes (behaviors) for them. The Smalltalk developers could have made t and nil be instances of the same class and dispensed with the True, False, and UndefinedObject classes (maybe rename Boolean to SimpleConstant -- or just use numbers, like in C, then we can get rid of BOTH booleans!) but they chose to put more structure in the definition than that. IMHO, there's nothing wrong with making more classes if it improves clarity. The point of writing in Smalltalk is to make the code clear. Lumping together different behaviors into the same class defeats this. Of course, it is a personal decision whether to use class or state to decide behavior. The true and false objects in Smalltalk are like quanta -- they are so primitive that their definition easily wavers between two objects of different classes and two objects of the same class. There must be a point where the system breaks down and becomes inconsistant (honest), and no matter which 'ugly wart' you remove, you'll find one more just waiting for you! -- -- Bill Burdick burdick@cello.ecn.purdue.edu