9

I'm writing some methods to emit HTML for various elements. Each method has the same output, but doesn't necessarily need the same input.

The method for echoing a game-board needs to take a player as well (because each player only sees their own pieces)

(defmethod echo ((board game-board) (p player)) ... )

Echoing a board space doesn't require changing per player (that dispatch is actually done in the game-board method, which later calls echo on a space). Ideally, I'd be able to do

(defmethod echo ((space board-space)) ... )
(defmethod echo ((space empty-space)) ... )

It's also conceivable that I later run into an object that will need to know more than just the player in order to display itself properly. Since there are already methods specializing on the same generic, though, that would give the error

The generic function #<STANDARD-GENERIC-FUNCTION ECHO (4)> takes 2 required arguments;

It seems less than ideal to go back and name these methods echo-space, echo-board and so on.

Is there a canonical way of varying other arguments based on the specialized object? Should I do something like

(defgeneric echo (thing &key player ...) ...)

or

(defgeneric echo (thing &rest other-args) ...)

? More generally, can anyone point me to a decent tutorial on defgeneric specifically? (I've read the relevant PCL chapters and some CLOS tutorials, but they don't cover the situation I'm asking about here).

Inaimathi
  • 13,853
  • 9
  • 49
  • 93

4 Answers4

5

Generally speaking if interfaces of two functions are too different it indicates that they are not actually a specializations of the same operation and should not have the same name. If you only want to specialize on optional/key arguments the way to achieve that is to use a normal function which calls a generic function and provides it with default values for missing arguments to specialize on.

Keene's book is, I believe, the most comprehensive guide to CLOS. Unfortunately it seems to be available only in book form.

Ramarren
  • 2,510
  • 1
  • 15
  • 11
  • Having a function dispatch on a generic seems less than satisfying (that would land me back in `echo-board`/`echo-space`/etc. territory). I think you're right in this case; I might be better off defining something like `echo` (to naively output single items) and a separate `echo-tailored` or similar (which would change its output based on additional parameters). – Inaimathi Feb 20 '12 at 19:27
  • The non-generic function doesn't do dispatch, it just canonicalizes the arguments. This obviously requires the generic (and so the methods) to take all possible arguments, which is why this is useful only when the interface is actually similar. – Ramarren Feb 21 '12 at 05:39
  • Here is a PDF of Keene's book (I don't know about how legal this is, please advise): https://doc.lagout.org/programmation/Lisp/Object-Oriented%20Programming%20in%20Common%20Lisp_%20A%20Programmer%27s%20Guide%20to%20CLOS%20%5BKeene%201989-01-11%5D.pdf – Alexis Dumas Jul 28 '17 at 23:56
3

It's easier whenever the methods take the same parameters but only differ on the data type. But in cases where the generic function and methods all use the same name (of course) yet have lambda lists that vary significantly, I personally tend to use &key parameters to make my intentions explicit, rather than using &optional parameters. I think it helps with readability later.

Try something like this (pretending we already have classes class-a and class-b):

(defgeneric foo (object &key &allow-other-keys)
  (:documentation "The generic function. Here is where the docstring is defined."))

(defmethod foo ((object class-a) &key &allow-other-keys)
  (print "Code goes here. We dispatched based on type Class A."))

(defmethod foo ((object class-b) &key (x 1) (y 2) &allow-other-keys)
  (print "Code goes here. We dispatched based on type Class B. We have args X and Y."))

Since "method combination" is involved, in order for the dispatching logic to "flow" through its possible choices of methods to use, we need to think of the method definitions somewhat like a chain where incompatible lambda lists (i.e. parameter lists) will break that chain. That's why there's the &key and &allow-other-keys in the method definitions that don't specifically need them. Putting them in DEFGENERIC and the method definitions allows us to have the method definition where we dispatch based on class-b.

DISCLAIMER: I'm a Common Lisp newbie myself, so take this with a grain of salt!

clintm
  • 1,259
  • 10
  • 23
RWalker
  • 86
  • 2
0

Stepped in the same problem today and found a nice workaround, but it will work only if you have a fixed number of class-specified args, placed at the beginning.

The example for the single class-specific arg:

(defgeneric foo (obj &rest args))

(defmacro my-defmethod (name args code)
  (let ((rst (gensym))
    `(defmethod ,name (,(car args) &rest ,rst)
       (apply (lambda (,(caar args) ,(cdr args)) ,code) (cons ,(caar args) ,rst)))))

(my-defmethod foo ((x class1) y z &optional a b c)
  ...)

(my-defmethod foo ((x class2) &key a b)
  ...)
Pavel
  • 363
  • 1
  • 2
  • 14
0

What about restructuring the objects/classes so that each object you want to echo has all required properties in its own (and inherited) slots?

That way you don't have to pass them as arguments when you call echo on the object, since what you need is already stored in the object.

Clayton Stanley
  • 7,513
  • 9
  • 32
  • 46