Every presentation type is associated with a CLOS class. In the common case, the name of the presentation type is a class object or the name of a class, and that class is not a clos:built-in-class . In this case, the presentation type is associated with that CLOS class.
Otherwise, define-presentation-type defines a class with metaclass clim:presentation-type-class and superclasses determined by the presentation type definition. This class is not named name, since that could interfere with built-in Common Lisp types such as and , member , and integer . clos:class-name of this class returns a list ( presentation-type name). clim:presentation-type-class is a subclass of clos:standard-class .
If the same name is defined with both clos:defclass (or defstruct ) and define-presentation-type , the clos:defclass (or defstruct ) must be done first.
Every CLOS class (except for built-in classes) is a presentation type, as is its name. If it has not been defined with define-presentation-type , it allows no parameters and no options. As in CLOS, inheriting from a built-in class does not work unless you specify the same inheritance that the built-in class already has; you may want to do this in order to add presentation-type parameters to a built-in class.
If you define a presentation type that does not have the same name as a CLOS class, you must define a presentation-typep presentation method for it. The function (as opposed to the presentation method) presentation-typep uses find-class if the presentation type is piggybacking on a CLOS type. Otherwise it depends on the user-defined presentation method.
If you define a presentation type that has parameters, you must define a presentation-subtypep for it. As noted previously, CLOS does not allow you to parameterize types, so you must provide a presentation-subtype method even for presentation types based on CLOS classes.
Note that CLIM itself depends on these methods for its own presentation-based utilities.
If your presentation type has the same name as a class, doesn't have any parameters or options, doesn't have a history, and doesn't need a special description, you do not need to call define-presentation-type .
During method combination, presentation type inheritance is used both to inherit methods ("what parser should be used for this type?"), and to establish the semantics for the type ("what objects are sensitive in this context?"). Inheritance of methods is the same as in CLOS and thus depends only on the type name, not on the parameters and options.
Presentation type inheritance translates the parameters of the subtype into a new set of parameters for the supertype, and translates the options of the subtype into a new set of options for the supertype.