Re: "data objects" vs "method objects"

[David.Ungar@Eng.Sun.COM (Dave Ungar)]

 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
>