Re: Documentation of nnoo.el

[Eric Abrahamsen]

Stefan Monnier <address@hidden> writes:

>> This is a bit nuts, but: are there any technical/policy obstacles to
>> considering an EIEIO re-write of Gnus? Nnoo.el is re-inventing the wheel...
>
> IIUC this wheel didn't exist, or was not widely available back then.
> But in any case, I can't answer because I don't understand nnoo.el
> (which gets us back to my request for documentation).

It's probably true EIEIO wasn't quite ready back in the day.

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.

I don't know much more than that because... it's not well documented.

>> Of course, who would actually go and do that is another question
>> altogether. But in principle?
>
> It all depends on how easy it is and what would be the benefits.

In principle it wouldn't be too hard: nnoo tries pretty hard to mimic
OO, so the paths are already in place. In practice, of course, I'm sure
it would be a huge pain.

Potential benefits:

1. Less code -- we could do away with a lot of redundancy.
2. Real object encapsulation. This is the main one in my mind -- right
   now it's easy to end up with variable leakage, and pretty hard to
   find the source of the leakage. Instead of switching global variable
   values as we switch servers, the servers themselves would just get
   passed around.
3. Easier hackage/extensibility. Contributors currently have very hard
   time figuring out how everything works; this would help. Subclassing
   would also make it much easier for people to write new backends, or
   modify existing ones.

Basically it looks like a textbook argument for the benefits of OO
programming.

Doing this would provide opportunities to fix some other odd things
about Gnus. Here's are a couple of suggestions for steps:

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.
2. Consider turning groups into classes. Group parameters would then be
   object slots. This might not be worth it.
3. Create a "marks-store" class: each server has its own object for
   storing marks. The default one would just write marks to a file.
   Subclasses could save marks to the cloud, etc. This would allow us to
   tackle the .newsrc.eld mess. If you look at bug
   reports/complaints/rants about Gnus, a very large proportion are
   related to marks somehow getting corrupted or out of sync. This would
   be a huge amount of work, though.

Anyway, those are my preliminary thoughts. Maybe someone else will chime
in. Probably to tell me I'm crazy!

Eric