Re: Documentation of nnoo.el

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> 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...

Eric