[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Documentation of nnoo.el

From: Eric Abrahamsen
Subject: Re: Documentation of nnoo.el
Date: Mon, 13 Jul 2015 10:56:28 +0800
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux)

Lars Magne Ingebrigtsen <address@hidden> writes:

> Eric Abrahamsen <address@hidden> writes:
>> nnoo.el is basically just an object-oriented system replicated with pure
>> functions. deffoo creates methods, defvoo creates slots. `nnoo-declare'
>> is kind of the equivalent of `defclass'. `nnoo-change-server' is the
>> main function for switching servers: it copies the defvoo slot values
>> for a single server into the respective global variables.
> Yup.  It was written that way (back in...  what?  94?) because there was
> some resistance to altering the "interface" defined by previous Gnus
> backends.  (See nnnil.el for a basic summary of what that is.)  By
> having Gnus switch around variables behind the backends' backs, the
> "interface" was preserved while Gnus could go on having multiple servers
> of the same type, etc.
> I don't know whether that was a good trade-off (keeping the interface
> vs. introducing lots of magic), but if I were to write that stuff now, I
> wouldn't do it that way.  :-)  I'd pass in explicit object describing
> the server state to each backend function, and I wouldn't have any
> "global" voo variables at all.

That's a lot earlier than I thought!

Does this mean you'd rather not go all the way with EIEIO? Maybe just
vectors or something?

> If anybody wants to rewrite all the backends that way -- please go ahead.

Well that's the real crux, isn't it :) I'm happy to try banging together
a preliminary example of how it might look. I don't think rewriting the
backends would be as much work as adjusting pretty much everything else
to use the new code.

>> 1. First, only make backends into classes. This would give us the chance
>>    to do away with the select-method/secondary-select-method
>>    distinction, and just have a list of defined servers.
> I think that's a totally orthogonal issue.  We could do that now, but
> it'd break the current naming scheme for the groups in Gnus.

It is orthogonal, but on the other hand it would take extra effort to
preserve. Do you mean the "nnml+ServerName:GroupName" scheme? I don't
quite see how doing away with the primary/secondary distinction would
affect that...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]