[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Compilation of methods per class.
- To: lange@cs.ucla.EDU
- Subject: Compilation of methods per class.
- From: egdorf%zaphod@LANL.GOV (Skip Egdorf)
- Date: Fri, 21 Sep 1990 11:08:20 PDT
- Cc: commonloops.PARC@xerox.com
- In-reply-to: "Trent Lange's message of Fri, 21 Sep 1990 07:00:26 PDT <900921.140026z.16258.lange@lanai.cs.ucla.edu>"
> Has anybody developed a method class that "compiles" methods
> by building a separate big lambda for each method on each class?
> The finalized method lambda for each class would have method selection
> and combination already done (with the code for auxiliary methods and
> call-next-methods embedded within them).
>
> ...
>
> - Trent Lange
> lange@cs.ucla.edu
This is essentially how KEE does its standard method combination.
In essence, the 'generic function' (slot with valueclass 'method' on the
unit representing the object owning the method) is built at method
definition time rather than at run time. The advantage, as you point out,
is that the single lambda representing the code to be executed is in
one place, compilable, etc.
The main disadvantage is that the CLOS style of method combination seems to
fit better with the Lisp style of late binding. The main effect of this is that
it becomes difficult to redefine a single method of the generic function at
run time, as it is hard to identify just what parts of the final lambda should
be removed, changed, or added to.
I have an implementation of a CLOS subset that allows defclass, defmethod, etc
to be used in a KEE environment with the implementation being in terms of
KEE units. This allows a very CLOS'y style to be used with existing KEE
applications. A big constraint is that I have not implemented any of the
redefinition portions of the CLOS spec due to the limitation described above.
Skip Egdorf
hwe@lanl.gov