egdorf@ZAPHOD.LANL.GOV (Skip Egdorf) (02/16/91)
> Skip, your critique of the alleged Symbolics statememnt on metaclass > capabilities seem a bit too strong to me. Jon, Thanks for your reasoned response. On later reading, mine is a bit more inflamatory than I had intended. Your points are all valid, but I retain a few worries from the position of a "user." It is unfortunate that the draft CLOS spec went out with "too much - too little" of the metaobject protocol in place. As a user of CLOS, I find the requirement to extend the functionality of classes, as well as my own objects to be very important. I think the examples here of retaining information on all instances of a class, or of adding a namespace for instances, are valid examples of the sorts of extensions that should be allowed to the users by the CLOS specification. As long as there is no "The" metaobject protocol, confusion will remain about just what parts of the MOP implied by the bits in chapters 1 and 2 can be portably used by programmers. Perhaps a reasonable solution (from the point of view of the users, if not from the point of view of the language developers and system implementers) would be to produce some agreement between major players such as Symbolics, Lucid, Franz, ... clarifying the behavior of some base set of those MOP bits in the existing parts of the spec. This would omit the original (?) intent of allowing CLOS to be used as an experimental base for different OO systems with metaclasses completely distinct from standard-class, but would allow basic modifications to existing behavior derived from standard-class. Such a list should probably include the following 1), 2), and 3). 4) would be nice for things like browsers, but would seem to start getting into the realm of "different possible implementations." 1) Use of :metaclass with classes defined as subclasses of standard-class, 2) Semantics of make-instance specialized on such classes 3) Some statement about the role of standard-object and how one might use a different base-class for the user's classes. 4) The basic readers (not accessors) for class-direct subclasses, class-direct-slots, and perhaps something allowing some access to method code for examination of combined methods. In summary, I feel that I need to use a bit of a MOP to extend (not replace) the functionality of the existing class structure. At the same time, I wish to be portable to the systems currently in house (Lucid and Symbolics) as well as adding (at least) MACL and Franz shortly. Responses like the workaround (?) presented by Symbolics thus worry me. > In the meantime, there are in fact some "de facto" standards in common > use for metaobjects. They are by no means complete, but do offer some > degree of stabililty. Explicitly, I refer to a mail message sent out > just about a year ago to the X3J13 email list detailing the three or four > dozen "metaobject protocol" functions and classes that Lucid and Symbolics > were agreeing to support. This is the sort of thing that I would like to see. Could you (someone) perhaps resurrect it for this list? How well are the vendors staying the course? > ... Virtually all of the functions and > features were drawn from previous versions of "Chapter 3" drafts, and > represent merely an "introspective" set (i.e., generic accessor-like > functions to fetch components of the major metaobject classes -- CLASSes, > GENERIC-FUNCTIONs, METHODs, and SLOT-DEFINITION's) > > Given all this background, I would hope that one could sift the metaobject > wheat from the chaff; ... Ah yes. And I feel that I really only need a little bit of the wheat. > -- JonL -- Skip Egdorf hwe@lanl.gov
jeff@aiai.edinburgh.ac.uk (Jeff Dalton) (02/16/91)
> Perhaps a reasonable solution (from the point of view of the users, if not > from the point of view of the language developers and system implementers) > would be to produce some agreement between major players such as Symbolics, > Lucid, Franz, ... Well, I don't really like this. We have a machanism (X3J13) that is fairly democratic and has a fairly wide base. I don't think we should resort to a different mechanism that is less democratic and less wide-based. Moreover, something may be reasonable for users of the "major players", but not necessarily for users in general. -- jd