... suppose you have a class (hierarchy) and a bunch of methods.

Now you want to add some before, after and around methods to your
application. With a constraint: no new classes can be introduced, and,
above all, user :before, :after and :around methods should work
without modifications. I.e. suppose I have

(defclass my-class (super1 super2 #|...|# superN) #|...|#)

(defmethod zut ((c my-class)))

(defmethod zut :before ((c my-class)))

(define-extra-method zut :before ((c my-class)) #|....|#)

I.e. How do I define the 'extra method' without clobbering the
(zut :before (my-class)) one?

NB. The solution "define a method combination" does not seem to work
because it'd require you to fix the method combination slot of the
generic function.
The "let's rewrite an :around method any time we do a
define-extra-method" seems better, but I foresee problems regarding
the definition environment and recompilation.

Anybody has some insight on this problem?

Kudos and cotillons to the person who figures out what I have been
looking at in the past two days. :)

Cheers

And why do you have a problem adding additional methods?
NORMALLY, only the person who maintains the code for a class
should be adding methods to it.  It's "impolite" to add methods
to a class you don't maintain the defclass for, IMO.
As such, if you own all the code, seems you're just saying
"I want half the code in one form and half in another" and
this problem reduces to the question:

I want to be able to do
(defun foo () ...)
and later
(defun-also foo () ...)
and I can't figure out how to jam two definitions into one function
cell.  That is, the problem isn't about CLOS at all, it's about
distributed function definition.

My take on this is that you have overconstrained the problem.
That doesn't mean there isn't an out, but it means you have to very
carefully examine each of your constraints and you have to be
pretty creative about what you can do in addition to what you
might have said.  For example, in the defun case, a possible solution
is
 (defun-some foo () ...)
 (defun-some foo () ...)
followed later by
 (ok-i\'m-done-defunning foo)
And such a solution would work in the clos case, too.

The problem you're having is that you're trying to still exploit
the "distributed definition" part of CLOS which relies on a shared
model of "how to merge a new definition with a previous one" yet you
haven't anywhere written code to do that merge.  Moreover, you are
neglecting that (method foo :after) amounts to a "name" in the sense
that the CLOS method combination code does bookkeeping under this name
and sees a further definition as a replacement of that name.  If you
want two "names" (two before methods), you need to make syntactic space
for the CLOS code to hold the two names, or else you shouldn't be
surprised that you can't wedge two definitions into the same mailbox.
Either you have to modify the system itself or you have to use external
storage, in which case you have to create a "time" when the seam-up
is done (such as the ok-xxx operator I had above) or you have to maintain
an auxiliary data structure so that every time a "definition" is done,
the "real definition" is recreated from scratch from the contributed parts
stored separately (which is what CLOS does).

That said, I have had to do the kinds of things Marco asks about in the
past.  When I was doing Lisp programming at Thinking Machines, we
occasionally needed to customize the behavior of internal mechanisms on the
Lisp system.  We generally used the ADVISE mechanism; this isn't standard,
but it was available in all the Lisp implementations we cared about
(Symbolics and Lucid).  This is essentially the "defun-also" mechanism that
the original poster asked about.

I usually use other devices for things that some people would do this
defun-also thing. e.g.,

 (in-package "A")
 (defvar *foo-hooks* '())
 (defun foo (x)
   (mapcar #'funcall *foo-hooks* (circular-list x))
   ...)
 - - - - - later module
 (in-package "B")
 (defun foo-also (x) ...)
 (push 'foo-also a:*foo-hooks*)

I do this for the NiCORE persistent object system, by having
a initialize-persistent-instance method that the system extends,
leaving the user to extend initialize.  In your case, you must
do it the other way because the system wasn't designed for
user extension:

(defmethod zut :around ((c my-class))
  (zut-extra-before c)
  (call-next-method)
  (zut-extra-after c)
  )

;; excuse the silkscript syntax..

(macro define-extra-method (name when args [body]*)
 (if (eq when :before)
   then
   `(method {(new-symbol name '-extra-before)} :before {args} {body}*)
   elseif (eq when :after)
    then
   `(method {(new-symbol name '-extra-after)}  :after {args} {body}*)  
   else
    ;; pick before or after
   `(method {(new-symbol name '-extra-after)} {args} {body}*)      
    ))

-Kelly Murray  k...@niclos.com
  NiCLOS engineering version released!  http://www.niclos.com/

I. Design for open implementation.  If you're designing an application
that you want users to be able to extend and customize, then THEY will
be under the constraints you give, but YOU will not.  YOU can define
additional classes and/or methods.  The common techniques are:
  A. Sprinkle dummy mixin classes into public ones.  This gives you a
place to
     hang new methods in patches, etc.  A typical arrangement is:
      (defclass FOO (custom-foo foo-implementation) ())
     where the implemenation hangs its methods on foo-implementation.
  B. Layer the major public methods with subprotocols.  As in the AMOP,
you
     will need to tell the user which methods can be overwritten or
extended,
     where extension is defined as something that still calls the
     implementation's method.
  C. Have your implementation call internal methods, which are layered,
and
     only document the things that it calls.  This gives you room to to
     specialize your code, while leaving the users to specialize the
public      
     stuff.

None of these help you where there is more than one independent body
which wants to be able to separately make customizations/patches which
can be simultaneously loaded.  For this I think you need some
formalization of the following...

II. Hacking an existing implementation.  Here the restrictions may
really be on you.  In addition to ADVISE, if available, remember that if
the CLOS MOP is available to you, you can write code which, at compile
time, locates currently existing applicable methods, grabs their
method-functions, and calls them explicitly within the body of the new
method.  You can glomm together as much as you want this way.  Be
careful, though, if you want to be able to reload such code (i.e. load
it more than once), then you'd better find a way to keep track of which
existing methods you're replacing, and making sure you don't call
yourself as many times as you have reloaded the code.  DEFVAR is your
friend.

Then again, my recollection is that the lisp machine uses a scheme
similar to what it sounds to me like you're proposing.  In that model,
there is an object that can live in a function cell which is an
"encapsulation" so that in addition to wrapping new definitions around
old ones, you can, for example, also notice that an existing
definition is encapsulated and decide to remove the 2nd innermost
encapsulation leaving the others in place.  This is used for tracing,
advising, and other things that share a common value cell.  But it
pretty much relies on the introspective leverage offered by saying
that the encapsulation is a first-class inspectable/manipulable object
with data components you can read and modify rather than just a black
box that you can funcall like CL functions basically are.

I'll try to address your objections, as I understood them:

1. If another :before DEFMETHOD with the same specializers is evaluated,
the existing method along with all the extra-methods should vanish. We
would be replacing the old definition (along with all the nexted closures)
with the new definition. At least I find this behavior intuitive. The
alternative is to have the extra-methods hang around irrespective of the
current definition of the :before method. I'm sure this could be done by
hacking into the MOP, but there might be an easier way (below).

2. The behavior of define-extra-method, as Marco has described it, is more
like an advice form, and as such *should* be order dependent. There is no
specification here as to the order in which the extra-methods should
execute. Indeed, there is not even a mechanism to identify them uniquely,
which would make it very difficult to redefine one particular extra method
if it is misbehaving.

I wholly agree that these restrictions would get in the way of flexibly
interacting with and debugging the functions. The best way to get around
this would be to attempt a method combination.

I have never had the need to define a method combination, so what I am
proposing might be severely broken. I'm going by my understanding, rather
than any implementation experience.

(defgeneric zut (c)
  (:method-combination chain))

(defmethod zut (chain :before 'for-some-reason) ((c my-class))
  ...)

My interpretation of method combinations is that CHAIN can be written to
generate a combination that collects multiple :before methods and executes
them all. The method definition rules at the same time should ensure that
the :before methods do not get redefined unless the reason matches. The
primary method will be one without a reason attached. This should address
all the problems the original proposal had. (If I had the time, I'd have
written some sample code and tested it out. Unfortunately...)

(defmethod zut chain :before fred ((c my-class))
  ...)

(deforder fred bill)

or some such. This should allow for changes in the priority mechanism
independent of the method definitions.

Issues of efficiency, flexibility etc. would have to be resolved at the
application level, so I guess it would be up to Marco to sort out the mess.

1. The proliferation of classes might not be desirable.

2. Subclasses are being used not to distinguish between types of data that
   are genuinely different. It is rather being used for obtain an effect in
   the methods you can define. A method combination would make this more
   obvious.

3. I'm not clear on what class you would make an object belong to. If you
   made an object a subclass of my-class, then creating subclasses of
   my-class for the purpose of method ordering would fail. If you defined
   my-class as a subclass of a set of classes on which you define the other
   methods, I imagine efficiency might become an issue. Further, you would
   need to provide the user with the ability to add a class at run-time if
   this type of ordering is to be part of the exported interface.

4. You would have to go ahead and define all those superclasses for any
   class on which you want this kind of behavior. With method combinations
   you would be able to restrict this behavior to specific generic
   functions rather than enforcing it across all generic functions.

Ok, I threw the stone and hid my hand :)

Many thanks to all who commented on the subject.

Somehow I had a hunch that method combination could do the (or at
least some) of the trick.  However, I am not so sure that it would
completely clear the issues. As it was pointed out, there are two main
sources of problems.

1 - Everything should be "redefinable".
2 - You do not have access to the actual method <body code>.

I kind of believe that, if not the full MOP, at least some
introspection into the <body code> of a method would be very useful.
Something like

        METHOD-BODY method => code object

Where code object is an immutable opaque structure which could be
combined - at least - in a PROGN like form, with something like

        MAKE-PROGN-METHOD-BODY &rest code objects => code object

Anyway, this may be asking too much; just like the encapsulation
machinery described by KMP.

All in all, I'd settle for the following scheme (I am veering off a
tangent here...) which, I believe, solves some of the problems of
Sunil's :must-follow, DEFORDER proposal.

Right now we can call a single :before or :after method.  I'd like a
method combination that could call a set (i.e. an ordered list) of
(:before :after) methods with the following specification (allow me
not to call it a 'method-combination')

        (defmethod zut :before :first (<method lambda list>) ...)
        (defmethod zut :before :last (<method lambda list>) ...)
        (defmethod zut :before <class> (<method lambda list>) ...)

(:before could be substituted by :after)

In the first case the :before (:after) method is guarateed to be added
first in the set of :before (:after) methods applicable in a given
method call.  The second case is the symmetric one: the method is
guaranteed to be added last.  Of course this introduces a "load eval
compile" order problem, but I presume it is something that can be
lived with.  The key here is that any "current" :before (:after)
method does not get clobbered.

The third case is the more interesting.

First of all let me note that I can rewrite all "standard" :before and
:after method definitions as

        (defmethod zut :before t (<method lambda list>) ...)

why will become clear in a sec.

This form tells me to order the set of :before and :after methods
applicable to a given actual <method lambda list> according to the CPL
of <class>. In particular, when two methods insist on the same <class>
(i.e. the case with 't') the second method defined clobbers the
first; as it happens now. I.e.

        (defmethod zut :before t ((s symbol)) 1)

        (defmethod zut :before t ((s symbol)) 2)

Will result in the call (zut 'foo) to return 2.

Let's see an example

(defclass zot ....)

(defmethod something-about-zot ((z zot)) ...)

;;; Let's add some debugging

(defmethod something-about-zot :before :first ((z zot))
   (format t ">>> ZOT debugging: calling SOMETHING-ABOUT-ZOT with ~S.~% z))

;;; and let's add some locking machinery to the class ZOT, on
;;; operation SOMETHING-ABOUT-LOCK.

(defvar zot-lock (make-lock))

(defmethod something-about-zot :before :first ((z zot))
   (seize-lock zot-lock))

(defmethod something-about-zot :after :first ((z zot))
   (release-lock zot-lock))

In this case I do not really care about the order of execution of the
debugging code and of the locking code. I just care that they get both
executed on operation SOMETHING-ABOUT-ZOT when called on a ZOT
instance.

Soppose I decide that debugging and locking must be executed in order.

I do

(defclass zot-debugging () ())
(defclass zot-debugging-and-locking (zot-debugging) ())

;;; Let's add some debugging

(defmethod something-about-zot :before zot-debugging ((z zot))
   (format t ">>> ZOT debugging: calling SOMETHING-ABOUT-ZOT with ~S.~% z))

;;; and let's add some locking machinery to the class ZOT, on
;;; operation SOMETHING-ABOUT-LOCK.

(defvar zot-lock (make-lock))

(defmethod something-about-zot :before zot-debugging-and-locking ((z zot))
   (seize-lock zot-lock))

(defmethod something-about-zot :after zot-debugging-and-locking ((z zot))
   (release-lock zot-lock))

Now I have the guarantee that debugging and locking code will be
execute according to the CPL of the classes mentioned in the
definitions.

How you'd compile this, I have no idea. It almost looks like that the
"add method" procedure would become a O(n^2) operation, but I am just
guessing here.

I do not even have an idea whether you could implement this as a
METHOD-COMBINATION (which would require you to declare all you generic
functions as having that particular method combination, which is a
no-no in my idea of how thing should be done.

Now, what are the advantages of this scheme.

First of all, IMHO, it is CLOS like.

Second, it does not require you to either (a) change the "original"
class hierarchy in order to accommodate the new operations you may add
as :before or :after methods and (b) it allows you to keep all your
"extra" code separated and organized according to intent or to the
"aspect" (this is the keyword :) ) you want to deal with.

Finally, I am indebted to Barry Margolin for his suggestion to look
into Gregor Kiczales' "aspect oriented programming". Two days reading
their papers and playing around with AspectJ made me waste some more
time thinking about these issues in CL.
http://www.parc.xerox.com/spl/projects/aop

Of course there is much more under the stars, than what can be
contained between two parenthesis :)

Cheers

ITOOGK (In The Opinion of Gregor Kiczales :-), there can be times and
places where moving in on the domain of a library both is usefull and
manageable, provided one adheres to some basic rules.

This is described and analyzed in a paper called

        Issues in the Design and Specification of Class Libraries

which is located at:

        http://www.parc.xerox.com/spl/groups/eca/pubs/papers/Kiczales-OOPSLA92

Hello

after some dreams during the night and a check on the
DEFINE-METHOD-COMBINATION spec. I believe that the sort of Aspect
Based Programming I described in my previous post can be very easily
implemented and - above all - integrated in CL.

A couple more days (after CODES99) and I'll be back with something. :)

Cheers

Cheers

I was reading iX yesterday and noticed an article about a new idea in
Java: Aspects, i.e. :before and :after methods. I'm stunned.

Did I miss something or is this just old wine in new bags?

Groetjes, Peter

So his ideas may get more of a hearing in the "Real World(tm)", OTOH
we will probably have to do our implementation of AOPs on our own ;)

Regs, Pierre.

Footnotes:
[1]  See http://www.parc.xerox.com/spl/projects/oi/ieee-software/ for
OI, and follow the links to AOP IIRC...

p...@acm.org (Pierre R. Mai) writes:

BTW. What name do you like? CLAP (CL Aspect Programming) or Hackspect? :)

Cheers