From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: emacs-devel@gnu.org
Subject: Re: Documentation of nnoo.el
Date: Sun, 12 Jul 2015 11:44:18 +0800 [thread overview]
Message-ID: <87k2u66nvx.fsf@ericabrahamsen.net> (raw)
In-Reply-To: jwv380uxgfn.fsf-monnier+emacs@gnu.org
Stefan Monnier <monnier@iro.umontreal.ca> 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
next prev parent reply other threads:[~2015-07-12 3:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-09 15:01 Documentation of nnoo.el Stefan Monnier
2015-07-12 1:32 ` Eric Abrahamsen
2015-07-12 2:25 ` Stefan Monnier
2015-07-12 3:44 ` Eric Abrahamsen [this message]
2015-07-12 11:17 ` Rasmus
2015-07-12 12:15 ` Eric Abrahamsen
2015-07-12 18:05 ` Lars Magne Ingebrigtsen
2015-07-13 2:56 ` Eric Abrahamsen
2015-12-24 16:59 ` Lars Ingebrigtsen
2015-12-25 3:44 ` Eric Abrahamsen
2015-12-26 22:11 ` Lars Ingebrigtsen
2015-12-27 1:03 ` Eric Abrahamsen
2015-12-27 6:03 ` Lars Ingebrigtsen
2015-07-12 17:55 ` Lars Magne Ingebrigtsen
2015-07-12 18:22 ` Nikolaus Rath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k2u66nvx.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.