GNU bug report logs -
#38252
27.0.50; Gnus server definitions and generic function specializers
Previous Next
Full log
View this message in rfc822 format
I'm working on changing Gnus servers into structs, and replacing the
nnoo.el architecture with generic functions, and while I think I've got
a workable roadmap I'm running into some practical confusions. Stefan
I'm ccing you directly because I suspect you're the only one who knows
the answers to my questions :)
The approach is this: Change the server interface functions in
gnus-int.el into generic functions. Provide a generalizer that
recognizes current Gnus servers, and dispatches to the current function
definitions (using `gnus-get-function' and all that). Gradually change
the in-tree backends to be defined with cl-defstruct, and use normal
dispatching-on-struct for those. Eventually the legacy generalizer would
be left in place just to deal with old-style out-of-tree backends.
As an example, here's what `gnus-request-list' currently looks like:
--8<---------------cut here---------------start------------->8---
gnus-int.el:
(defun gnus-request-list (gnus-command-method)
(funcall (gnus-get-function gnus-command-method 'request-list)
(nth 1 gnus-command-method)))
nnimap.el:
(deffoo nnimap-request-list (&optional server)
<get IMAP group list>)
--8<---------------cut here---------------end--------------->8---
Afterward it would look like this:
--8<---------------cut here---------------start------------->8---
gnus-int.el:
(cl-defgeneric gnus-request-list (server)
"Docs and stuff.")
(cl-defmethod gnus-request-list ((server gnus-server-legacy))
(funcall (gnus-get-function server 'request-list)
(nth 1 server)))
nnimap.el:
(cl-defmethod gnus-request-list ((server gnus-server-imap))
<get IMAP group list>)
--8<---------------cut here---------------end--------------->8---
The nnimap version will dispatch on the `gnus-server-imap' defstruct,
that happens automatically. What I need is to be able to write a
generalizer/specializer that will recognize a legacy server (if calling
it "legacy" is annoying I can find something else) and dispatch on it.
The docstring of `cl-generic-define-generalizer' is gnomic, though I
found some better information in the docstring of
`cl-generic-generalizers', and looked at some of the existing
generalizer definitions.
Here's what I've worked up so far:
--8<---------------cut here---------------start------------->8---
(cl-generic-define-generalizer gnus-legacy-server-generalizer
90 (lambda (name &rest _) `(???)
(lambda (tag &rest _) (when (eq (car-safe tag) 'gnus-legacy-server)
(list tag))))
(cl-defmethod cl-generic-generalizers :extra "gnus-legacy-server" (thing)
"Dispatch on old-style Gnus server definitions."
(when wut?
(list gnus-legacy-server-generalizer)))
--8<---------------cut here---------------end--------------->8---
What I'm trying to do is fairly simple: if the argument is a list, and
the head of the list is a symbol that can be assoc'd into
`nnoo-definition-alist', and the second element is a string, then it's a
gnus-legacy-server. I just don't know where that test is supposed to go,
or why.
I understand this will probably be inefficient and ugly, but I hope that
before too long it would be a rare case that the generalizer is checked
at all.
Thanks,
Eric
This bug report was last modified 5 years and 213 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.