john@LINUS.MITRE.ORG (03/19/91)
andreasg@sigi.Colorado.EDU (Andreas Girgensohn) writes: > I would prefer that different methods of the same generic functions > could have different numbers of required parameters. The selection > of the applicable method(s) would depend on the number of parameter > in addition to the types of the parameters. I would also like to be > able to specialize optional parameters. I don't think it makes sense to specialize on &OPTIONAL parameters. For instance, think about: (DEFMETHOD PRINT-SOMETHING ((X MY-THING) &OPTIONAL (STREAM SPECIAL-STREAM)) (PRINT-MY-THING-INTERNAL X STREAM)) Here, (STREAM SPECIAL-STREAM) is meant to indicate the specialization of the optional argument STREAM, not its default value. Let's not even bother discussing the necessary (but horrible!) additions to the syntax that would distinguish between specializations and default values. Is this method applicable if I do the following? (PRINT-SOMETHING (MAKE-MY-THING)) No, one might say, because I'm implicitly passing in the value NIL for the STREAM parameter. What if the default value for STREAM in that method was (MAKE-SPECIAL-STREAM)? Well, it depends on whether default values are assigned before or after method applicability is determined. I think this could be argued either way, although I'd lean towards after, in which case the method would still not be applicable. This all sounds rather dubious, however. Then, consider the question of what the lambda list for a generic function looks like if its methods don't have congruent lambda lists, e.g. (DEFMETHOD PRINT-SOMETHING ((X FOO) &OPTIONAL STREAM) ...) (DEFMETHOD PRINT-SOMETHING ((X BAR) STREAM) ...) What is the lambda list for the function PRINT-SOMETHING? I don't know, but this doesn't make me believe that non-congruency is a good idea. Everyone probably knows what "the right thing" is. Trouble is, none of them are the same "right thing".
bane@tove.cs.umd.edu (John R. Bane) (03/20/91)
In article <9103181745.AA18191@mingus.mitre.org> john@LINUS.MITRE.ORG writes: > >I don't think it makes sense to specialize on &OPTIONAL parameters. >For instance, think about: > > (DEFMETHOD PRINT-SOMETHING ((X MY-THING) &OPTIONAL (STREAM SPECIAL-STREAM)) > (PRINT-MY-THING-INTERNAL X STREAM)) > >Here, (STREAM SPECIAL-STREAM) is meant to indicate the specialization >of the optional argument STREAM, not its default value. Let's not >even bother discussing the necessary (but horrible!) additions to the >syntax that would distinguish between specializations and default >values. I think that specializing on &OPTIONAL parameters makes perfect sense, but mainly in the syntactically godawful case you mention, when the &OPTIONAL parameters have default values specified. If there is a specified default, then as far as the generic function is concerned, the parameter is always specified, and should be no different from a required parameter for method lookup. To really make it make sense, the requirement should be that all &OPTIONAL parameters have a default expression, and that congruent parameters have the SAME default expression. If you want to think about REALLY awful syntax, consider the possibility of specializing on the svar predicate of an &OPTIONAL parameter: (DEFMETHOD PRINT-SOMETHING ((X MY-THING) &OPTIONAL ((STREAM SPECIAL-STREAM) *DEFAULT-STREAM* (STREAM-SUPPLIED (EQL NIL)))) This method obviously ;-) gets run when the STREAM argument is not supplied and its default value in *DEFAULT-STREAM* is a SPECIAL-STREAM. -- Internet: bane@tove.umd.edu UUCP:...uunet!mimsy.umd.edu!bane