[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: user interface macros
- To: Gregor J. Kiczales <firstname.lastname@example.org>
- Subject: Re: user interface macros
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 7 May 90 17:52 EDT
- Cc: David Gray <email@example.com>, Cyphers@STONY-BROOK.SCRC.Symbolics.COM, Jon L White <firstname.lastname@example.org>, Danny Bobrow <email@example.com>, firstname.lastname@example.org, Richard P. Gabriel <email@example.com>, Dussud@Lucid.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, mop.pa@Xerox.COM
- In-reply-to: <19900507200704.4.GREGOR@SPIFF.parc.xerox.com>
- Line-fold: No
Date: Mon, 7 May 90 13:07 PDT
From: Gregor J. Kiczales <Gregor.PA@Xerox.COM>
My proposal (admittedely cluttered by typos)
was to specify a minimal, simple behavior for DEFCLASS and DEFGENERIC
processing of non-standard options. Enough to get some power out of
it, but by no means fully featured. We would also say explictly that
an implementations are free to extend or modify this behavior.
Single appearance options which simply quote their value would be
supported by the minimal, specified behavior. For anything else you
would need to use your own macro or implementation-specific tools. I
believe This will get enough more than saying nothing about how
non-standard options are passed through that it is worth doing.
I guess I need to see a version that is not cluttered with typos, since
it seems to me that if you specify something and say that implementations
are free to modify it, you have not specified anything.