Jecel Assumpcao wrote:
I don't see any practical difference between "inheritance" and "delegation"
Me neither. I pointed that out just to make a difference between what Self has and what is commonly referred by inheritance (including Wegner=B4s classification), that is, Class Inheritance. Anyway, I see inheritance as a useful, although not mandatory feature.
With this definition, Smalltalk is not *pure* OO.
Because of the classes? See "Smalltalk with
Examplars" or CoDA for
Smalltalks with classless objects.
No. With "definition" I meant the previous one: "Objects communicating through message passing". One example: Smalltalk accesses variables directly, not by message passing. OK, it=B4s not a big deal, but illustrates my point.
But I prefer not to fight for any particular meaning
of "OO"
I tend to agree. It is not all that important having an exact definition. But my scientific spirit makes me love the purist approach that led to great research pursuing a clean and pure OO (such as the Self project). This utopic and minimalist sense is much related with simplicity, that is one of the things I love the most about objects, and what IMHO made Smalltalk what it is.
Regards, Dan Rozenfarb
__________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
Just for the record ....
In Smalltalk-72, variables were theoretically objects, and thus required quoting in order to do assignment. So 'a meant give me the symbol a BTW " ' " is an actual object in Smalltalk-72 a meant give me the value that is associated with the symbol a the symbol a would look itself up in the current context to find the value 'a <- foo meant send the message "<- foo" to the symbol a which would look itself up in current context and store the value a <- foo meant send the message "<- foo" to the object associated with the symbol a etc.
In retrospect, it might have been a better idea to use the opposite convention instead of one that worked like LISP -- so a symbol would be a literal (like a number), and there would have been a message to get the value associated with it. But maybe not ...
Also, a number of inheritance ideas were tried out in Smalltalk-72, none of which I liked all that much. My favorite were the "slot inheritance" experiments that were done by Larry Tesler.
Cheers,
Alan
-------
At 8:40 AM -0700 4/27/02, Dan Rozenfarb wrote:
Jecel Assumpcao wrote:
I don't see any practical difference between "inheritance" and "delegation"
Me neither. I pointed that out just to make a difference between what Self has and what is commonly referred by inheritance (including Wegner=B4s classification), that is, Class Inheritance. Anyway, I see inheritance as a useful, although not mandatory feature.
With this definition, Smalltalk is not *pure* OO.
Because of the classes? See "Smalltalk with
Examplars" or CoDA for
Smalltalks with classless objects.
No. With "definition" I meant the previous one: "Objects communicating through message passing". One example: Smalltalk accesses variables directly, not by message passing. OK, it=B4s not a big deal, but illustrates my point.
But I prefer not to fight for any particular meaning
of "OO"
I tend to agree. It is not all that important having an exact definition. But my scientific spirit makes me love the purist approach that led to great research pursuing a clean and pure OO (such as the Self project). This utopic and minimalist sense is much related with simplicity, that is one of the things I love the most about objects, and what IMHO made Smalltalk what it is.
Regards, Dan Rozenfarb
Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
--
hi Alan
Also, a number of inheritance ideas were tried out in Smalltalk-72, none of which I liked all that much. My favorite were the "slot inheritance" experiments that were done by Larry Tesler.
What was slot inheritance?
Stef
Because of the classes? See "Smalltalk with
Examplars" or CoDA for
Smalltalks with classless objects.
Coda is not about classless objects. Just a mop for objects but objects where instances of classes.
stephane ducasse (home) wrote:
What was slot inheritance?
Stef
As I understand it that was a precursor of delegation a la Lieberman and then Self and so on: inheritance goes via the slots instead of via the class.
But this understanding is based on very scarce information.
Henrik
Slot inheritance was invented for AI and other reasoning systems -- and also for providing protection of polymorphic meanings. One of the ways of looking at it is that for many objects, the contents of the instance variables can be thought of as "parts". Thus, one could imagine a lookup strategy that would search down through the instance variables for ideas and info about the object. An example might be to deal with the question "how heavy?" the idea might be to look at the slot called "material" and ask the actual value for help. It could in turn ask its variables for help, etc. So this gives a dynamic way to enlarge the property space of an object. If you include the static superclass chain in the mix of searched variables, then you get regular inheritance. This is one of the many inheritance strategies used in CYC. Another view of this is to consider the polymorphic meaning of "print" in Smalltalk. There is no protection of the generic meaning, any programmer can write whatever they want in a method. However, we could make a subclass of class Method called Print whose instances are Print-Methods. These would not allow arbitrary code to be written in them, but might have places where programmers could add useful ideosyncratic information. All of these print methods would really try to print something. So slot classes and slot inheritance allow real definitions and protections of meanings. This idea also goes back to the early 70s.
All these were easy to do in ST-72 because each class/closure/instance really got passed control *before* the message was received. There were some suggestions that a "prereceive" method be allowed in ST-76 and -80 -- if present, a flag would be set somewhere efficient, and it would be called first with the actual message put in a place where it could be received later. This would have allowed all of these schemes, delegation, etc., to also be done in the later versions of ST. Someone on the list might want to figure out good ways to do these schemes in Squeak. Folks like Nathanial Scharli and Stephane, who are playing with metasystems, should add these kinds of considerations into their play.
Etc.
Cheers,
Alan
-------
At 3:32 PM +0200 5/1/02, Henrik Gedenryd wrote:
stephane ducasse (home) wrote:
What was slot inheritance?
Stef
As I understand it that was a precursor of delegation a la Lieberman and then Self and so on: inheritance goes via the slots instead of via the class.
But this understanding is based on very scarce information.
Henrik
--
There were some suggestions that a "prereceive" method beallowed in ST-76 and -80 -- if present, a flag would be set somewhere efficient, and it would be called first with the actual message put in a place where it could be received later. This would have allowed all of these schemes, delegation, etc., to also be done in the later versions of ST. Someone on the list might want to figure out good ways to do these schemes in Squeak. Folks like Nathanial Scharli and Stephane, who are playing with metasystems, should add these kinds of considerations into their play.
Hmm, how about an additional format in the object format field of the base header with a special method entry in the method dictionary (like a key of 0 ...it could be called the zero method)? This would allow for a "prereceive" method for all instances of any given class.
To actually do delegation, you would still need a couple of primitives/bytecodes that supported a delegated send (where the current receiver gets propogated to the new method context...so that sends to the receiver flow back to the original receiver). I think I have a pretty good implemenation of the basic delegation primitives/bytecodes (see http://spair.swiki.net/delegation). Of course, a "prereceive" method would be useful for much more that simple delegation.
- Stephen
Alan Kay wrote:
There were some suggestions that a "prereceive" method be allowed in ST-76 and -80 -- if present, a flag would be set somewhere efficient, and it would be called first with the actual message put in a place where it could be received later. This would have allowed all of these schemes, delegation, etc., to also be done in the later versions of ST. Someone on the list might want to figure out good ways to do these schemes in Squeak. Folks like Nathanial Scharli and Stephane, who are playing with metasystems, should add these kinds of considerations into their play.
I've thought of a similar scheme where a similar message is sent only if a method is not found in the receiver's own local method dictionary (alt. in the whole superclass chain--you can use doesNotUnderstand: to similar effect). Then you can do whatever you need to find/build the method to be used. That way you can also cache methods that you've thus found/built by putting them in the local MethodDict. These two things allow you to cut down the number of times the expensive method find/build call has to be performed when it isn't needed.
Henrik
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Dan Rozenfarb -
Henrik Gedenryd -
stephane ducasse -
Stephen Pair