Ahoy,
I have added a file called HACKING that's supposed to explain how to hack the code for people joining the project.
Corrections welcome!
Luke Gorrie luke@bluetail.com writes:
Ahoy,
I have added a file called HACKING that's supposed to explain how to hack the code for people joining the project.
Corrections welcome!
Nice document!
You write:
If a reasonable default implementation can be provided, we do so in swank-backend.lisp by specializing NO-APPLICABLE-METHOD [or is that a bad idea? -luke].
I didn't even know about NO-APPLICABLE-METHOD :-). But, I would expect that the default implementation is added as method for the generic function itself and not to NO-APPLICABLE-METHOD.
Our current Elisp code sometimes calls SWANK-exported functions that are not defined by DEFSLIMEFUN, but by DEFGENERIC in swank-backend.lisp. [Is it just me that does this, and should I stop it? -luke]
We could invent a macro like DEFSLIMEGENERIC, or something with a shorter name. Probably not a bad idea, because some of the generic functions are called in swank.lisp and others by Emacs directly.
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
I didn't even know about NO-APPLICABLE-METHOD :-). But, I would expect that the default implementation is added as method for the generic function itself and not to NO-APPLICABLE-METHOD.
The idea of NO-APPLICABLE-METHOD was t'be sure that a "real" definition would override the default one. Could we do this using normal methods? (I'm not wise in the ways of CLOS.)
We could invent a macro like DEFSLIMEGENERIC, or something with a shorter name. Probably not a bad idea, because some of the generic functions are called in swank.lisp and others by Emacs directly.
Or how about:
(slimefun foo) (defgeneric foo ....)
(slimefun bar) (defun bar ....)
Luke Gorrie luke@bluetail.com writes:
The idea of NO-APPLICABLE-METHOD was t'be sure that a "real" definition would override the default one. Could we do this using normal methods? (I'm not wise in the ways of CLOS.)
I think so. If we don't specialize any argument all other method would be more or equal specific. More specific methods should be called first and equally specific methods redefine the default implementation.
We could invent a macro like DEFSLIMEGENERIC, or something with a shorter name. Probably not a bad idea, because some of the generic functions are called in swank.lisp and others by Emacs directly.
Or how about:
(slimefun foo) (defgeneric foo ....)
(slimefun bar) (defun bar ....)
How about:
(defslime (fun bar) ..) (defslime (generic bar) ..) (defslime (var bar) ..)
:-)
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Luke Gorrie luke@bluetail.com writes:
The idea of NO-APPLICABLE-METHOD was t'be sure that a "real" definition would override the default one. Could we do this using normal methods? (I'm not wise in the ways of CLOS.)
I think so. If we don't specialize any argument all other method would be more or equal specific. More specific methods should be called first and equally specific methods redefine the default implementation.
The worry is we'll get a lot of "You're redefining FOO" warnings. The reason I started using defgeneric+defmethod instead of defun+defun was to avoid those (and also to keep the docstring).
But maybe it's nearly moot? We'll likely remove most of my first-cut at multiprocessing, and it's the only stuff using default methods so far.
-Luke
-
Helmut Eller -
Luke Gorrie