Macro

Summary

Defines an implementation class for a particular set of interfaces.

Package

com

Signature

define-com-implementation class-name (superclass-name*) (slot-specifier*) class-option*

Arguments

class-name

A symbol naming the class to define.

superclass-name

A symbol naming a superclass to inherit from.

slot-specifier

A slot description as used by defclass.

class-option

An option as used by defclass.

Description

The macro define-com-implementation defines a standard-class which is used to implement a COM object. Normal defclass inheritance rules apply for slots and Lisp methods.

Each superclass-name argument specifies a direct superclass of the new class, which can be another COM implementation class or any other standard-class provided that com-object is included somewhere in the overall class precedence list. To get the built-in handling for the i-unknown interface, inherit from standard-i-unknown (which is the default superclass if no others are specified).

The slot-specifiers are standard defclass slot definitions.

The class-options are standard defclass options. In addition the following options are recognized:

(:interfaces interface-name*)

Each interface-name specifies a COM interface that the object will implement. i-unknown should not be specified unless the you wish to replace the standard implementation provided by standard-i-unknown. If more than one interface-name is given then all the methods must have different names (except for those which are inherited from a common parent interface).

(:inherit-from class-name interface-name*)

This indicates that the class will inherit the implementation of all the methods in the interfaces specified by the interface-names directly from class-name. The class-name must be one of the direct or indirect superclasses of the class being defined. Without this option, methods from superclasses are inherited indirectly and can be shadowed in the class being defined. Use of :inherit-from allows various internal space-optimizations.

For example, given a COM class foo-impl which implements the i-foo interface, this definition of bar-impl:

(define-com-implementation bar-impl (foo-impl)

    ()

    (:interfaces i-foo))

will allow methods from i-foo to be shadowed whereas this definition:

(define-com-implementation bar-impl (foo-impl)

    (:interfaces i-foo)

    (:inherit-from foo-impl i-foo))

will result in an error if a method from i-foo is redefined for bar-impl.

(:dont-implement interface-name*)

This option tells standard-i-unknown that it should not respond to query-interface for the given interface-names (which should be parents of the interfaces implemented by the class being defined). Normally, standard-i-unknown will respond to query-interface for a parent interface by returning a pointer to the child interface.

For example, given an interface i-foo-internal and subinterface i-foo-public, the following definition

(define-com-implementation foo-impl ()

    ()

    (:interfaces i-foo-public))

specifies that foo-impl will respond to query-interface for i-foo-public and i-foo-internal, whereas the following definition

(define-com-implementation foo-impl ()

    (:interfaces i-foo-public)

    (:dont-implement i-foo-internal))

specifies that foo-impl will respond to query-interface for i-foo-public only.

Examples

(define-com-implementation i-robot-impl ()

  ((tools :accessor robot-tools))

  (:interfaces i-robot)

  )

(define-com-implementation i-r2d2-impl (i-robot-impl)

  ()

  (:interfaces i-robot i-r2d2)

  )

See also

define-com-method
standard-i-unknown