Article View: comp.lang.clos
Article #468Specializing on &OPTIONAL parameters (was moooo!)
From: john
Date: Wed, 20 Mar 1991 17:09
Date: Wed, 20 Mar 1991 17:09
58 lines
3116 bytes
3116 bytes
bane@tove.cs.umd.edu (John R. Bane) writes:
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.
First of all, &OPTIONAL parameters always have a default default :-)
value, NIL. So there's no such thing as an &OPTIONAL parameter with
no default value. Second, your comment makes it sound like failing to
specify a value for an &OPTIONAL parameter when calling a function is
the same as specifying the default value. I don't agree. The default
value is just a convenient way to specify what to do when the caller
doesn't specify a value. If non-specification and specifying the
default were the same thing, why does CL provide the ability to
distinguish between them? (I'm referring to the SVAR predicate for
&OPTIONALs, which John mentions later.)
Consider the following method:
(DEFMETHOD ADD-CONDIMENT ((FOOD HAMBURGER)
;; Condiment defaults to ketchup
&OPTIONAL (CONDIMENT :KETCHUP))
...)
If someone uses the following call:
(ADD-CONDIMENT *BIG-MAC*)
they are NOT specifying the CONDIMENT parameter, and method lookup
should NOT depend on what they've failed to specify.
I definitely don't agree that congruent &OPTIONAL parameters in
different methods should have the SAME default expression. The point
of a method is to specify the behavior of a function when some of the
function's arguments are of particular types. Given that, I think it
makes perfect sense for the method to also specify what to do when
certain parameters are unspecified. Consider the previous
ADD-CONDIMENT method along with the following:
(DEFMETHOD ADD-CONDIMENT ((FOOD TUNA-FISH-SANDWICH)
&OPTIONAL (CONDIMENT :MAYONNAISE))
...)
The default condiment to use depends on the food.
In fact, if all default values for a particular &OPTIONAL parameter
were the same in all methods, and you could specialize on that
parameter, how much good would it do you? All of your specializations
would have to include the default value, so it doesn't sound very
useful.
John Burger
Technical Details
Message-ID:
<9103201709.AA20839@mingus.mitre.org>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbageShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage From: john@LINUS.MITRE.ORG Newsgroups: comp.lang.clos Subject: Specializing on &OPTIONAL parameters (was moooo!) Message-ID: <9103201709.AA20839@mingus.mitre.org> Date: 20 Mar 91 17:09:04 GMT Sender: welch@tut.cis.ohio-state.edu Distribution: inet Organization: CommonLoops Lines: 58