* bug#38252: 27.0.50; Gnus server definitions and generic function specializers
@ 2019-11-17 22:31 Eric Abrahamsen
2019-11-18 2:03 ` Stefan Monnier
0 siblings, 1 reply; 5+ messages in thread
From: Eric Abrahamsen @ 2019-11-17 22:31 UTC (permalink / raw
To: 38252; +Cc: larsi, monnier
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#38252: 27.0.50; Gnus server definitions and generic function specializers
2019-11-17 22:31 bug#38252: 27.0.50; Gnus server definitions and generic function specializers Eric Abrahamsen
@ 2019-11-18 2:03 ` Stefan Monnier
2019-11-18 3:18 ` Eric Abrahamsen
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2019-11-18 2:03 UTC (permalink / raw
To: Eric Abrahamsen; +Cc: larsi, 38252
> I'm ccing you directly because I suspect you're the only one who knows
> the answers to my questions :)
I doubt it, there's a lot of people around here more familiar with
CLOS-style programming than I.
> --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)))
Why not just:
(cl-defmethod gnus-request-list (server)
(funcall (gnus-get-function server 'request-list)
(nth 1 server)))
which means "use it as a fallback". The downside is that it will be
used for non-legacy servers if there is no specific implementation for
that server, but presumably you can detect it and signal an appropriate
error somewhere inside gnus-get-function.
> 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.
Why not just use a `cons` specializer?
IIUC all the non-legacy servers will use structs, so you don't need to
use a specializer that's so specific that it has to check "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".
Stefan
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#38252: 27.0.50; Gnus server definitions and generic function specializers
2019-11-18 2:03 ` Stefan Monnier
@ 2019-11-18 3:18 ` Eric Abrahamsen
2019-11-18 4:36 ` Stefan Monnier
0 siblings, 1 reply; 5+ messages in thread
From: Eric Abrahamsen @ 2019-11-18 3:18 UTC (permalink / raw
To: Stefan Monnier; +Cc: larsi, 38252
On 11/17/19 21:03 PM, Stefan Monnier wrote:
>> I'm ccing you directly because I suspect you're the only one who knows
>> the answers to my questions :)
>
> I doubt it, there's a lot of people around here more familiar with
> CLOS-style programming than I.
>
>> --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)))
>
> Why not just:
>
> (cl-defmethod gnus-request-list (server)
> (funcall (gnus-get-function server 'request-list)
> (nth 1 server)))
>
> which means "use it as a fallback". The downside is that it will be
> used for non-legacy servers if there is no specific implementation for
> that server, but presumably you can detect it and signal an appropriate
> error somewhere inside gnus-get-function.
>
>> 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.
>
> Why not just use a `cons` specializer?
>
> IIUC all the non-legacy servers will use structs, so you don't need to
> use a specializer that's so specific that it has to check "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".
Okay, perhaps I was overthinking this. I don't want to assume that the
fallback is an old-style server (we might want to use the fallback for
other purposes), but you're right that 'cons is pretty much sufficient.
If anyone feeds a cons value into a Gnus server interface function that
*isn't* a server definition, that falls into "serves you right"
territory.
But just so I don't feel like I wasted my afternoon: how *would* one
write the generalizer I'm talking about?
Thanks,
Eric
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#38252: 27.0.50; Gnus server definitions and generic function specializers
2019-11-18 3:18 ` Eric Abrahamsen
@ 2019-11-18 4:36 ` Stefan Monnier
2019-11-18 20:43 ` Eric Abrahamsen
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2019-11-18 4:36 UTC (permalink / raw
To: Eric Abrahamsen; +Cc: larsi, 38252
> But just so I don't feel like I wasted my afternoon: how *would* one
> write the generalizer I'm talking about?
Ah, that part.
I guess It could look like (guaranteed 100% untested):
(defvar gnus--legacy-server-tag (make-symbol "gnus-legacy-server"))
(cl-generic-define-generalizer gnus-legacy-server-generalizer
90 (lambda (varname &rest _)
`(and (consp ,varname)
(symbolp (car ,varname))
(assq (car ,varname) nnoo-definition-alist)
(stringp (cadr ,varname))
gnus--legacy-server-tag))
(lambda (tag &rest _)
(when (eq tag gnus--legacy-server-tag) (list tag))))
(cl-defmethod cl-generic-generalizers ((_ (eql gnus-legacy-server)))
"Dispatch on old-style Gnus server definitions."
(list gnus-legacy-server-generalizer))
-- Stefan
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#38252: 27.0.50; Gnus server definitions and generic function specializers
2019-11-18 4:36 ` Stefan Monnier
@ 2019-11-18 20:43 ` Eric Abrahamsen
0 siblings, 0 replies; 5+ messages in thread
From: Eric Abrahamsen @ 2019-11-18 20:43 UTC (permalink / raw
To: Stefan Monnier; +Cc: larsi, 38252
On 11/17/19 23:36 PM, Stefan Monnier wrote:
>> But just so I don't feel like I wasted my afternoon: how *would* one
>> write the generalizer I'm talking about?
>
> Ah, that part.
> I guess It could look like (guaranteed 100% untested):
>
> (defvar gnus--legacy-server-tag (make-symbol "gnus-legacy-server"))
> (cl-generic-define-generalizer gnus-legacy-server-generalizer
> 90 (lambda (varname &rest _)
> `(and (consp ,varname)
> (symbolp (car ,varname))
> (assq (car ,varname) nnoo-definition-alist)
> (stringp (cadr ,varname))
> gnus--legacy-server-tag))
> (lambda (tag &rest _)
> (when (eq tag gnus--legacy-server-tag) (list tag))))
>
> (cl-defmethod cl-generic-generalizers ((_ (eql gnus-legacy-server)))
> "Dispatch on old-style Gnus server definitions."
> (list gnus-legacy-server-generalizer))
That's perfect, thanks. I don't need tested code, I just needed to
understand the logic of which bit is responsible for what. I wonder if
it would be useful to have an example of this, either in the manual or
cl-generic.el code comments?
There's still a lot of work to do before struct servers and cons servers
can coexist within Gnus, but it's nice to have this piece of the puzzle
solved.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-11-18 20:43 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-11-17 22:31 bug#38252: 27.0.50; Gnus server definitions and generic function specializers Eric Abrahamsen
2019-11-18 2:03 ` Stefan Monnier
2019-11-18 3:18 ` Eric Abrahamsen
2019-11-18 4:36 ` Stefan Monnier
2019-11-18 20:43 ` Eric Abrahamsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.