I agree, and the original language paper by Randy & me takes this view. The problem is that this is a hard story to maintain when pushed. For example, data objects return themselves but methods clone themselves when they run. How do you account for the cloning? Or if everything clones, how does a data-object refer to the clone-father? Also, the implementation falls a bit short in hiding the differences.

But, this unification is a wonderful platonic ideal that we do strive for.

Dave

From owner-self@self.stanford.edu Sun Sep 15 20:44:09 1991 Return-Path: thinkage!Thinkage.On.CA!scott@watmath.waterloo.edu Date: Sun, 15 Sep 91 23:39:10 EDT To: self-interest@self.stanford.edu Subject: "data objects" vs "method objects" Content-Length: 1071 X-Lines: 23

Just a thought on how the papers and manuals explain how objects are evaluated w.r.t "data objects" vs "method objects". It seems to me that no distinction is necessary or desirable between these two "types" of objects.

An object should simply be viewed as something containing a bunch of slots, and a method. An object that is supposed to behave like data (i.e., no explicit method) should implicitly be given a method which is simply "self".

Describing objects this way would make things seem even more uniform -- the manuals would no longer have to state that "Data objects are objects without code" or that "A data object returns itself when evaluated"; all objects simply execute their method when they are evaluated, and return the result. Since the method for "data objects" is "self", everything falls out in the wash.

[Eg: (|x.y|) should be described as an abbreviation for (|x.y| self).]

-- Scott M. King Thinkage Ltd. Kitchener, Ontario, Canada smking@Thinkage.On.CA smking@Thinkage.com uunet!thinkage!smking