[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

JOIN



    From: Jim Meehan <Meehan>
    Re:   JOIN

    It's in T 2.6, though it wasn't in 2.5.  Does this mean that it's
    officially released?  Also, is JOIN the appropriate mechanism to use
    for implementing the dynamic addition of methods to objects?

The fact that the variable JOIN is bound in T 2.6 is misleading.  Its
value is a procedure which does something quite random.  JOIN will
appear in some later release; it has relatively high priority.

I'm still working on the problem of dynamic method manipulation, and
haven't come up with a satisfactory solution.  One possible future
solution is to combine JOIN with SYNONYM, but that has its drawbacks.

Regarding defining methods for structures, there are two alternatives,
neither of which is in the manual, and both of which involve
side-effects, which is not considered good.

(a) Use undocumented special form HANDLER:
	(SET (STYPE-HANDLER FOO-STYPE)
	     (HANDLER ((PRINT SELF STREAM) ...)
		      ...))

(b) Use undocumented special form DEFINE-METHODS:
	(DEFINE-METHODS (STYPE-HANDLER FOO-STYPE)
	  ((PRINT SELF STREAM) ...)
	  ...)

The use of these two mechanisms is mutually exclusive.  Considering that
neither is very good, and neither has a clear advantage, they will
probably both stay around for awhile, so suit yourself as to which you
use.

If you don't mind using features which may go away, there is also
a procedure MAKE-MUTABLE-HANDLER, and an => syntax in OBJECT, which you
can use roughly as follows (I find this to be pretty distasteful,
but there's nothing better right now):

	(DEFINE H (MAKE-MUTABLE-HANDLER 'H))

	... (OBJECT ...			; [1]
		    ((OP1 SELF ...) ...)
		    ...
		    (=> H))

	(DEFINE-METHODS H
	  ...
	  ((OP2 SELF ...) ...)		; [2]
	  ...)

The objects created by [1] will use the "mutable handler" H to handle
operations.  H may be built up incrementally using several distinct
DEFINE-METHODS forms.

Lexical scoping is kind of a loss here, since the variables lexically
apparent at [1] aren't apparent at [2].