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


Issue METACLASS-OF-SYSTEM-CLASS Writeup

Issue:        METACLASS-OF-SYSTEM-CLASS

Reference: X3J13/92-102, dpANS 12.24

Section 4.3.7, "Integrating Types and Classes", p.4-16..418

X3J13/92-3105, Kim Barrett comment #5

Category: CHANGE

Edit History: Version 1, 1/6/93, Kim Barrett

Status: Proposal UNSPECIFIED accepted, March 1993

Problem Description:

The fifth and seventh paragraphs on p.4-17 say

Each \term{class} that corresponds to a predefined \term{type specifier}

can be implemented in one of three ways, at the discretion of each

implementation. It can be a \term{standard class}, a

\term{structure class}, or a \term{built-in class}.

It is possible to determine whether a \term{class} is a

\term{built-in class} by checking the \term{metaclass}. A

\term{standard class} is an \term{instance} of \theclass{standard-class},

a \term{built-in class} is an \term{instance} of

\theclass{built-in-class}, and a \term{structure class} is an

\term{instance} of \theclass{structure-class}.

This prohibits implementations from using implementation-specific metaclasses

which are not subclasses of one of the three defined metaclasses

(STANDARD-CLASS, STRUCTURE-CLASS, and BUILT-IN-CLASS). This prohibition

gratuitously limits implemention freedom, since it serves no useful purpose

for users.

Depending on how the uses of the term \term{instance} are disambiguated in

the second paragraph, it may actually be making the stronger requirement that

\term{direct instances} of these metaclasses be used.

Proposal (METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED):

Change the fifth paragraph on p.4-17 by replacing the occurance of the term

\term{built-in class} with the term \term{system class}, so that it says

Each \term{class} that corresponds to a predefined \term{type specifier}

can be implemented in one of three ways, at the discretion of each

implementation. It can be a \term{standard class}, a

\term{structure class}, or a \term{system class}.

Editorial Impact:

One tiny edit.

Rationale:

Allows system classes to be implemented using implementation specific

metaclasses that are not themselves subclasses of any of the standardized

metaclasses, and therefore can be implemented in whatever manner is

deemed appropriate by the implementor without the need to override possibly

undesirable features of the inherited standardized metaclass.

Examples:

(typep (find-class 'stream)

'(or standard-class structure-class built-in-class))

\EV \term{implementation-dependent}

Current Practice:

Of the half dozen implementations I checked, none obeyed even the

weaker of requirements mentioned in the problem description.

Cost to Implementors:

None. This does not require any implementation to change.

Cost to Users:

Small. Any program that was specializing some generic function on

standard-class, structure-class, and built-in-class (with the idea that this

covered all the possibilities) would have to change. Such a program is

already non-portable. The obvious change is to instead specialize on class.

Performance Impact:

None.

Discussion:

This issue was discussed extensively in private mail during February 1992,

under the Subject line "implementation of a system class".


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