[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
user interface macros: the environment issue
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM, gregor@parc.xerox.com
- Subject: user interface macros: the environment issue
- From: Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.COM>
- Date: Mon, 7 May 90 11:31 EDT
- Cc: mop.pa@Xerox.COM
- In-reply-to: <19900507151408.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Mon, 7 May 90 11:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Gray said:
I would want to see the need for that demonstrated first.
So I think we agree that we're not yet convinced such a predicate is
needed. Gregor hasn't addressed this issue yet.
Let's start by addressing the question of whether any predicates on
environments are needed at all, and if so, what exactly those predicates
are testing for. My strawman proposal is that the metaobject protocol
documents no operations on environments other than the ones that are
already in 88-002R (such as the environment argument to FIND-CLASS) and
obvious extensions of the same thing. Thus no run-time versus
compile-time predicate at all. Let's look at where this breaks down,
if at all, to see whether there is a need for anything else. I know
it will break down for users writing their own macros that do what
DEFCLASS does. I haven't yet been shown a case where it will break down
for users writing methods that get called by the expansion of any of the
defining macros.
A DEFCLASS expands into a compile-file time ENSURE-CLASS and a load time
ENSURE-CLASS. If the class has slots with :CLASS allocation, then their
initforms get evaluated when the class is instantiated (probably by a
SHARED-INITIALIZE method). The compile-time ENSURE-CLASS shouldn't call
the initfunctions, so the SHARED-INITIALIZE method is going to have to
look at the environment argument to determine whether or not to call any
initfunctions.