#

## 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".

Copyright 1996-2001, Xanalys Inc. All rights reserved.