[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issues for the CLOS committee to start focussing on
- To: Common-Lisp-Object-System@SU-AI.ARPA
- Subject: Issues for the CLOS committee to start focussing on
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 8 Jan 87 23:25 EST
The following issues need to be resolved and documented by February 4
(to allow a document to be distributed before the March X3J13 meeting).
If we cannot resolve these among ourselves this month, we should put a
brief explanation of the open issues into the document. That way, the
document will accurately reflect our current status.
We only have three weeks, so let's try to focus on the important points
as much as possible and get some solid results down on paper.
>>> HIGH PRIORITY
Consistent terminology
- names for relationships among classes
- names for predefined classes & other interesting entities
- describing the terminology at the front of the document
- making sure the document adheres everywhere to the chosen terminology
(this may have been resolved already, but we were still discussing
it quite recently)
Initialization protocol.
(I have not yet started on this. I plan to think about it next week.)
Method-combination.
(I plan Friday to mail out complete documentation incorporating the
results of the recent discussion)
The class precedence rules, description, and algorithm. To a certain
extent these are three separate issues.
(Dick has been working on this, but I don't think it's resolved yet)
What happens when the partial order of class precedence admits more than
one total order.
(Currently the document says that it is recommended to signal an
error. I used to think that was a good idea, until I tried
implementing it and applying it to some real-life programs.
I reported on the results in a message of 22 Nov 86.
I firmly believe the order has to be well-defined, not
implementation-dependent, and cannot be considered an error.
Depth-first tree-walk order appears to be the correct disambiguator.)
We need to define quite explicitly the inheritance behavior of class
options and slot options. There should be a table listing each option
and showing how it inherits.
>>> LOWER PRIORITY
Structure of the classes for standard Common Lisp types. This means
which types have corresponding classes, and what the subclass and
precedence relations are.
(I thought this was resolved last year but the document doesn't
reflect that.)
Class redefinition and change-class protocol.
(I have not yet started on this)
Class variables.
(Discussion is ongoing, probably almost finished)
with-slots interning issue.
(Discussion is ongoing, probably almost finished)
Minor issues about which I sent mail as document comments, and
discussion doesn't seem to be continuing.
(Unless there are objections, I plan to proceed assuming
these are resolved, and update the documents accordingly.)
>>> LOWEST PRIORITY
Uninitialized slots (signal an error or return garbage?)
(Discussion is ongoing, probably almost finished)
Method lambda-list congruency rules.
(The document says these are a first approximation. This issue is
almost finished, but the rules for keywords might be wrong.)
MAKE-CLASS, REMOVE-CLASS.
(nothing in the document)
Some of the functions in the Functions chapter don't make sense
without the rest of meta-objects. Perhaps it should be reorganized
into two chapters.
:interface and :method-arguments options to defgeneric-options.
(These are currently out, but might go back in
once method-combination is fully clarified.)