[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: remote environments
- To: Sandra J Loosemore <email@example.com>
- Subject: Re: remote environments
- From: Gregor.pa@Xerox.COM
- Date: Mon, 13 Mar 89 10:22 PST
- Cc: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Sandra.J.Loosemorefirstname.lastname@example.org, David N Gray <Gray@DSG.csc.ti.com>, Patrickemail@example.com, Dussud <firstname.lastname@example.org>, Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, email@example.com, firstname.lastname@example.org
- Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
- In-reply-to: <8903131444.AA02017@defun.utah.edu>
- Line-fold: no
Date: Mon, 13 Mar 89 07:44:15 MST
From: email@example.com (Sandra J Loosemore)
At least three of us (Moon, Gray, and myself) appear to agree that
DEFMETHOD should not make the method function callable at compile time
(by analogy to DEFUN). If you're using the term "initfunctions" to
refer to things like the SHARED-INITIALIZE method, then no, they can't
be called at compile-time by default.
Yes, I understood that. I didn't mean to suggest that it was an open
question, just that it was a basic question. Answering it as we have
has some implications that I don't fully understand yet. More on that
in a second.
Personally, I think we could leave the issue of whether remote classes
exist or are instantiable unspecified for now. It would give those of
you who are trying to sort out the meta-object protocol more freedom,
and I don't think it would place an unreasonable burden on programmers.
This misses the major point from my message (looking back at my message,
the point is obscured). The funny thing about specifying `meta-level'
behavior is that while we can specify minimal behavior, we can't specify
minimally. In short, I think we have to take a stand on whether there
are remote metaobjects or not.
We must decide so that users who define their own metaobject classes can
know under what conditions those classes will be instantiated. If a
user defined metaobject class is instantiated in the remote environment
some things will be `different'. At the very least it will have these
funny remote functions. User code needs to know that it must deal with
I believe it is possible to take a minimal stance on what we specify.
One such workable minimal stance is to say that no portable metaobject
class will ever be instantiated in the remote environment. In this
scheme, the implementation could instantiate its own metaobjects in the
remote environment, and it could instantiate placeholders for user
metaobjects as well. This would make it possible to do the kind of file
compilation we all know and love when doing normal programming. Only
portable `compilers' would have to use the load, then compile approach.