Generic Function Parameter and Metho d Parameter Metaob jects: A Prop osed Enhancement to the CLOS Metaob ject Proto col Eric L. Peterson Arti cial Intelligence Technologies Center MITRE Corp oration 1820 Dolley Madison Blvd. McLean, VA 22102-3481 e-mail: [email protected] URL: http://www.cs.umd.edu/users/ericp phone: (703) 883-6116 FAX: (703) 883-6435 April 25, 1996 Abstract Common Lisp's Metaob ject Proto col de nes classes of ob jects whichembody various asp ects of the ob ject oriented programming environment. Current such metaob jects represent classes, slots, generic functions, metho ds, as well as other ob ject oriented entities. Not currently included, however, are ob jects that represent generic function and metho d parameters. This pap er rst gives class de nitions declaring the b ehavior of these prop osed parameter metaob jects and then pro ceeds to argue for for their inclusion in the exp ected addition of the Metaob jects Proto col to the ANSI Common Lisp Standard. 1 Intro duction The Common Lisp Ob ject System's (CLOS) Metaob ject Proto col (MOP), as put forth in The Art of the Metaobject Protocol (AMOP) [2], provides metaob jects representing many asp ects of the state of the 1 2 dynamic ob ject oriented program. It is widely embraced as a de facto standard. Perhaps the largest asp ect of the ob ject oriented program still untamed by the MOP is the rendering of the actual metho d co de as a network of ob jects. This pap er, however, is concerned with the taming of a simpler asp ect. 2 The Prop osal This pap er argues for the incorp oration of ve new instantiable metaob ject classes as well as their ancestors into the CLOS MOP prior to the MOP's incorp oration into the Common Lisp ANSI standard. These metaob jects represent generic function (GF) and metho d parameters. Their instantiable classes are as follows: standard-generic-function-parameter standard-method-parameter standard-optional-parameter standard-rest-parameter 0 Eric Peterson is a memb er of the Machine Translation Group at the Arti cial Intelligence Technologies Center at the MITRE Corp oration. Thanks go to Lawrence Mayka and David Tereb essy for review comments and to Lawrence for the CLIM example/argument. 1 The term MOP, in this pap er will b e understo o d to mean the AMOP MOP. 2 Slight di erences in metaob ject proto cols exist b etween Common Lisp implementations. 1 standard-keyword-parameter The rst two parameters represent the required parameters from generic function and metho d lambda lists resp ectively. The remaining parameter metaob jects represent non-required parameter information 3 and are to b e used in either generic function or metho d lamb da lists containing non-required parameters. Please see Figure 1 for the de nitions of these classes and for the descriptive information found in their CLOS do cumentation strings. This prop osed family of metaob jects would require a new defmethod -like macro to allow for the input of metadata b eyond what is found in a standard defmethod macro. See Figure 2 for an example use of such a macro. The conventional defmethod macro would still b e available , but would serve to load conventional parameter information into metaob jects of the kind describ ed in this pap er. It would still serve ordinary ob ject oriented programming needs in the traditional fashion. The new macro would b e for those who wish to do cument their parameters in a run-time retrievable fashion, as well as for those who which to asso ciate additional information with those parameters. To some, it may app ear overly verb ose, yet it should b e noted that it is no more verb ose than the CLOS slot sp eci cations within the defclass macro. In b oth cases, terse representations would not allow for seamless addition of non-standard attributes as is done by the sub classing of slot de nition metaob jects. Both standard-generic-function and standard-method ,two existing MOP metaob jects, would receive 4 a new slot called parameters . The lists would not contain the traditional &optional , &rest , &key , and &al low-other-keys delimiter tokens. None would b e needed, b ecause the typ es of the metaob jects would b e immediately determinable. An additional sibling slot to parameters would b e called al low-other-keys and would take the place of the lamb da list token of the same name and would serve as a b o olean indication as to whether other keys would b e allowed. The following ve new GF's would b e added to the MOP: generic-function-parameter-class method-parameter-class optional-parameter-class rest-parameter-class keyword-parameter-class They would b e analogous in purp ose to the e ective-slot-de nition-class GF. They would allow the CLOS user/extender to communicate the presence of parameter metaob ject sub classes to the CLOS/MOP environment.f It may b e argued that supplied-p do es not b elong in a parameter metaob jects b ecause it has nothing to do with the sp eci cation of the GF/metho d interface. Although it is clearly a piece of utility information for the b ene t of the metho d(s)' lexical environment, this prop osed change, like current lamb da lists, makes no distinction b etween interfacespeci cation , and utility information. It is prop osed that any information that is logicall y asso ciated with such a parameter, is not only welcome, but encouraged to b ecome part of a parameter metaob ject. &aux parameters would simply b e treated as if macro expanded into let expressions, as is presently 5 done. They would have no metaob jects. Caching of parameter metadata would, as allowed by the MOP, b e p ermitted. Therefore, implemen- tations would b e free to create and cache conventional lamb da lists in GF and metho d metaob jects. Implementations could thus obtain runtime p erformance identical to their present implementation s for generic dispatch not involvin g additional parameter metadata from user enhanced parameter metaob- jects. 3 The term non-required is used to refer to &optional , &rest , and &keyword parameters. The term optional would, of course, have b een ambiguous. 4 Both the use of the term slot and the use of class de nitions with slots are for exp ository convenience. Precisely sp eaking, such b ehavior could b e implemented without the use of slots. Assume that the b ehavior is as if de ned as shown. 5 Future work alluded to later in this pap er will require metaob jects for program variables in order to house variable related metadata. This suggests the p ossibility that metaob jects for auxiliary variables would b e needed as well. 2 (defclass parameter (clos:metaobject) ((parameter-name :type symbol :documentation "The name of a lambda list parameter" :accessor parameter-name) (parameter-documentation :type string :documentation "User supplied documentation of parameter" :accessor parameter-documentation :initarg :documentation)) (:documentation "Information pertaining to a given lambda list parameter")) (defclass standard-generic-function-parameter (parameter)() (:documentation "Information pertaining to a generic function parameter")) (defclass standard-method-parameter (parameter) ((method-parameter-specializer :type (or symbol list) :documentation "Parameter specializer for generic dispatch" :accessor method-parameter-specializer :initarg :specializer :initform t)) (:documentation "Information pertaining to a given method parameter")) (defclass optional-parameter (parameter) ((optional-parameter-default :documentation "Default value for &optional parameters" :accessor optional-parameter-default :initarg :default :initform nil) (optional-parameter-supplied-p :documentation "An indication of whether the calling function supplied the argument" :accessor optional-parameter-supplied-p :initarg :supplied-p :initform nil) (optional-parameter-type :type (or symbol list) :documentation "Non-specializing type information" :accessor optional-parameter-type :initarg :type :initform t)) (:documentation "Information pertaining to a given &optional parameter")) (defclass standard-optional-parameter (optional-parameter) () (:documentation "Information pertaining to a given parameter")) (defclass standard-rest-parameter (parameter) () (:documentation "Information pertaining to a given &rest parameter")) (defclass standard-keyword-parameter (optional-parameter) ((keyword-parameter-keyword :documentation "For when the keyword is different from the parameter name" :accessor :keyword-parameter-keyword :initarg :keyword)) (:documentation "Information pertaining to a given &key parameter")) Figure 1: Generic function and metho d parameter metaob jects would b ehave as if sp eci ed by these class de nitions. Metaob ject classes whose names b egin with standard are instantiable. 3 (defmethod+ foo ((bar-param :specializer float :documentation "bar parameter documentation" :unit-of-measure :kilopascals) &optional (baz-param :type float :default bar-default-value :supplied-p bar-supplied-p-value :documentation "bar documentation" :unit-of-measure :kilopascals) &key (blat-param :type float :keyword :blat-actual-keyword :default blat-default-value :supplied-p blat-supplied-p-value :documentation "blat documentation" :unit-of-measure :joules)) ...) Figure 2: An example use of the prop osed defmethod -like macro. Parameter attributes are sp eci ed in CLOS defclass slot de nition fashion. CLOS users not needing or wishing this much representational p ower would simply use defmethod in the traditional manner. 3 Motivations 3.1 Adding Parameter Metadata 3.1.1 Parameter Do cumentation Perhaps the most commonly felt desire for more parameter representational p ower is the desire to b e able to add runtime accessible do cumentation to GF and metho d parameters. Although such information could b e placed somewhere in a mo di cation of the existing lamb da list, if the parameters were presently implemented as ob jects, these ob jects would b e a convenient place for the parameter do cumentation to reside.