[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: remote environments
- To: Gregor.pa@Xerox.COM
- Subject: Re: remote environments
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Mon, 13 Mar 89 07:44:15 MST
- Cc: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Sandra.J.Loosemore%defun@cs.utah.edu, <sandra%defun@cs.utah.edu>, David N Gray <Gray@DSG.csc.ti.com>, Patrick%defun@cs.utah.edu, Dussud <dussud@lucid.com>, Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Gregor.pa@Xerox.COM, Sun, 12 Mar 89 20:00 PST
> Date: Sun, 12 Mar 89 20:00 PST
> From: Gregor.pa@Xerox.COM
>
> If there is a remote class object then we must solve what I previously
> previously called the `splicing' problem. That remote class object must
> have pointers to other class objects which represent its superclasses.
> If that is the case, then to some extent that remote class will be
> instantiable. Any class that has direct supers can be finalized
> provided that none of the supers are forward referenced. Since it can
> be finalized, allocate-instance can be called. So, the only real
> question is whether the initfunctions can be called. From the user's
> point of view, that translates into whether make-instance can be called.
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.
Of course, if you really those methods to be callable at compile time,
you can always wrap an explicit (EVAL-WHEN (EVAL COMPILE LOAD) ...)
around both the class and method definitions. Alternatively, you'd
probably put the definitions in another file and load it before
compiling the file that wants to instantiate that class at compile
time.
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.
> But, do we need remote metaobjects to do this? I have argued before
> that we don't. I believe it would be a reasonable restriction on
> such portable programs that the program they are `compiling' be loaded
> before it can be compiled. No one has shown me why that isn't the case.
I guess this is pretty much the same thing as I was saying above. The
one reservation I have (that others have also expressed) is that the
common practice of a file containing a class definition followed by
method definitions on that class should compile properly without
having to do any magic with pre-loading the file or wrapping
EVAL-WHENs around everything. Would that cause problems for the
meta-object protocol?
-Sandra
-------