[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Issue CONDITION-SLOTS Writeup

Issue:         CONDITION-SLOTS

References: Condition System, version 18

Issue CLOS-CONDITIONS

Issue PACKAGE-CLUTTER

ANSI CL draft pp.5-4, 5-5

Category: CLARIFICATION

Edit history: 3-Jan-90, Version 1 by Barrett

30-Apr-90, Version 2 by Moon (rewrite, just one proposal,

extend to cover all specified objects that have slots)

Problem description:

Pages 5-4 and 5-5 of the ANSI CL draft specification from last fall refer

to slots of specified conditions. However these slots were not put into

the specification in a consistent way.

CLOS-CONDITIONS:INTEGRATE, which was adopted by X3J13, changed condition

slots to be the same as CLOS slots, but did not say that the specified

conditions have any specified slots. However, some people have taken it

to mean that the condition classes defined by the standard all contain

slots whose names are external symbols in the CL package which are

STRING= to the specified initargs for creating conditions. The ANSI CL

draft specification was edited in some places as if this were true.

Revision 18 of the conditions document, which was adopted by X3J13,

refers to initialization arguments and accessors, but carefully avoids

naming the slots themselves. The philosophy of that document was that

slots are only defined for programmer defined conditions, and that the

only sanctioned interface for the standard condition classes is through

the use of the defined accessor functions.

A related, more general issue that PACKAGE-CLUTTER:REDUCE failed to

address is whether there are naming restrictions on

implementation-dependent slots of specified classes.

This is Symbolics issue #8 and Loosemore issue #15 of 27 Feb 90.

Proposal (CONDITION-SLOTS:HIDDEN):

1. Clarify that no specified condition classes have any specified slots.

The implementation of the required information storage by the specified

condition classes is implementation-dependent. We need to be clear that

specified conditions are not required to have any particular slots with

any particular names. They -are- required to be the type of object that

is able to have slots. User-defined conditions -are- required to have

slots with the names mentioned in the DEFINE-CONDITION form.

2. Table 5-1 in the ANSI CL draft specification should not contain slot

names, because they will not necessarily be accessible via WITH-SLOTS in

the way people might infer. Instead, the table should mention initargs

and accessors. For example, :FORMAT-STRING and

SIMPLE-CONDITION-FORMAT-STRING -- but not the symbol FORMAT-STRING.

3. Define that it is unspecified whether slots are involved in the

operation of specified functions on instances of specified classes,

except when slots are explicitly specified by the standard.

4. Define that if in a particular implementation a specified class has

slots that are not specified by the standard, the names of these slots

must not be external symbols of packages defined in the standard nor

otherwise accessible in the USER package.

Rationale:

Allowing the information storage to be implementation-dependent is

essential to compatibility with existing systems, which may not represent

this information in the "obvious" way.

Specifying slots for the condition classes would require putting the slot

names into the COMMON-LISP package, adding many symbols.

Part 4 of the proposal repairs an omission in PACKAGE-CLUTTER:REDUCE. It

is necessary if users are to be able to define a subclass of a condition

class (which is necessary whenever users define their own conditions) and

give slots to their class without potentially interfering with

implementation-defined slots.

Current practice:

Parts 1 through 3 are likely to be consistent with all existing

implementations. Part 4 is not known to be specifically violated by any

implementation, but it might well be violated by accident. I have not

tested any implementations specifically.

Cost to Implementors:

Easy, all they have to do is keep slot names out of user visible packages.

Cost to Users:

Easy, all they have to do is use the specified accessors rather than

SLOT-VALUE or WITH-SLOTS to access information in conditions.

Cost of non-adoption:

Substantially increased size of the COMMON-LISP package and considerable

extra work on the ANSI CL specification to document all the slots.

Porting problems for any code that defines its own condition types

because of slot name collisions.

Performance impact:

None of any consequence. SLOT-VALUE might be faster than calling an

accessor in some implementations (although in most implementations it is

slower, when not called from a method), but access to a slot of a

condition never occurs in important inner loops.

Benefits:

Conditions will be specified as originally intended.

Esthetics:

Abstraction is better than mandating one particular implementation

of information storage.

Discussion:

None.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.