This is another one of ThomasKuehne's patterns -- PhilGoodwin
by maintaining a dispatch table that associates parameter types with FunctorObject
s. When a GenericFunction
is called it uses the dynamic types of its parameters as keys into the dispatch table in order to retrieve a specialized FunctorObject
. The call is then delegated to the FunctorObject
Of course the implementation of a GenericFunction
is not required to consider only type information in the dispatch. It may consider the values of the parameters or even (in unusual cases) other information about the state of the program.
is a FunctorObject
for a GenericFunction
. It provides parameterization of HigherOrderFunction
s with polymorphic behavior.
s are the preferred implementation of ExternalPolymorphism
for use with the TranslatorPattern
The attributes of the parameters that are to be used as selection criteria are assembled into a key which is then used to retrieve a Specialized
Function from a map. The original call is then delegated to the Specialized
Function. The canonical attribute to use as a selection criteria is, of course, the type of the parameter. Therefore some mechanism is generally needed to retrieve type information from objects at runtime. Some languages have this built in. Others may require potentially intrusive measures in order to implement it by hand.
In the context of the CommonLispObjectSystem
the term "generic function" denotes a function whose behavior depends on the classes or identities of the arguments supplied to it and whose parts include, among other things, a set of methods, a lambda list, and a MethodCombination type
(quoted from the CommonLispHyperSpec
). Conversely, within CLOS the term "method" is defined to mean an object that is part of a generic function and which provides information about how that generic function should behave when its arguments are objects of certain classes or with certain identities.
Also see the sections "Introduction to Generic Functions" (http://www.lispworks.com/reference/HyperSpec/Body/07_fa.htm
) and "Introduction to Methods" (http://www.lispworks.com/reference/HyperSpec/Body/07_fb.htm
) in the CommonLispHyperSpec
for detailed explanations.
These two definitions are basically in harmony. The first describes a "workaround pattern" which gives you something like Lisp generic functions, in a weak OO programming language. Since in the weak language you don't have the "deluxe" object-oriented dispatch mechanism over all of the arguments, you hack it together yourself by creating an object that has registered functors, and selects among them. These are analogous to CommonLisp
methods, which are associated with a generic function.
Also, in Lisp, functions are objects, so there is no distinction between GenericFunction
. If you define a (defgeneric foo (a b)) you can indirect upon it easily: (mapcar #'foo list-of-objects) and so on. This gives you an instant VisitorPattern
in a box.
CategoryObjectFunctionalPatterns CategoryCommonLisp CategoryPolymorphism