What I currently do is the "_Define _AddSlots:" cliche Dave Ungar posted. Out of interest, I checked back through my archive of the mailing list - almost _two years ago_, Bill Burdick and Bay-Wei Chang, I think, seemed to work this one out.
Urs Hoelzle writes:
- Through the programming environment.
Something I've seen recently (came over the net) is Kevo, yet another prototype prototype-based OOPL. (this one is a mutant FORTH). Although prototype based, it claims not to provide inheritance; rather, everything is managed by clever copying. So where we inherit, Kevo just copies and does _AddSlots. The catch is that Kevo has another version of _AddSlots with adds the slots to each member of a group of objects. Where we would modify a parent, Kevo modifies each object in the group. Kevo has three levels of "propagation": an individual object; a object and all unmodified copies (clones); an object and all modified copies of the object (descendants).
This approach could (in fact) be implemented in Self as it stands, with judicious use of the Mirror references methods. And (I think) were some of the information in the compiler's object maps brought out to the programmer (browse all objects cloned from this object) this would be even easier. I think this would be more within the style of Self than adding complicated constraints to the programming environment - but that's just my opinion. Adding general constraints to the language - say like Brad Myer's KR object system in Lisp - now there's an idea!
WRT Kevo, I think the author (Antero Taivalsaari) will be at OOPSLA for those of you lucky enough to be going :-) I don't particularly like Kevo (although I'm happy to believe it may be the best OO FORTH - CUP TEA OF MY FORTH IS NOT). And, as far as I can see, the Kevo scheme (using copying rather than inheritance, with mechanisms for managing copying) is no more powerful than inheritance and has one big drawback: the inheritance hierarchy is no longer manifest in the program's basic structure.
kjx
(Self bigot flame mode on) Hmm - I guess Self (at over two years in public release) must be considered a "mature" language now. I'm sure that's older than the latest version of C++ for instance! (Self bigot flame mode off)
kjx
Date: Fri, 25 Sep 1992 15:00:01 +1200 From: R James Noble kjx@comp.vuw.ac.nz Resent-To: real-self-interest@otis.Stanford.Edu Resent-Date: Fri, 25 Sep 92 7:58:25 PDT Resent-From: Urs Hoelzle urs@otis.Stanford.Edu
This approach could (in fact) be implemented in Self as it stands, with judicious use of the Mirror references methods. And (I think) were some of the information in the compiler's object maps brought out to the programmer (browse all objects cloned from this object) this would be even easier. I think this would be more within the style of Self than adding complicated constraints to the programming environment - but that's just my opinion. Adding general constraints to the language - say like Brad Myer's KR object system in Lisp - now there's an idea!
Hey I'm interested in adding KR-like constraints to Self too! And I'm working for Brad on Garnet, using KR. KR is a prototype based object system on top of Common Lips, an AI-style frames system, with inheritence and constraints. The constraints are one way formulas that get invalidated when other slots they depend on change. Not heavy duty crunchy mathematical constraints, but more like data flow programming. They are very very useful for building user interfaces. I suppose you could implement them on top of Self, using constraint accessor methods in slots instead of plain values and assignment primitives. But KR supports the constraints directly, on top of lisp, but at the object system level, and I don't know how efficient it would be to implement them as a layer on top of the object system in Self. It could be nice to have direct support for constraints in the language.
Garnet has "aggregadgets" which are very cool -- aggregate prototypes, that let you do stuff like instantiate (say) a button prototype that's made out of nested groups of graphical objects, and then change the prototype (say change the direction of the drop shadow, or the font), and the changes propagate to all the instances in the user interface!
-Don
PS: But Michael Powell says you need a PhD to program in Lisp, so maybe we should be implementing all this stuff in C++, which he says is the best object oriented programming language in the world!
self-interest@lists.selflanguage.org
-
Don Hopkins -
R James Noble