From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Documentation of nnoo.el Date: Sun, 12 Jul 2015 11:44:18 +0800 Message-ID: <87k2u66nvx.fsf@ericabrahamsen.net> References: <87615q88kh.fsf@ericabrahamsen.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1436672690 3236 80.91.229.3 (12 Jul 2015 03:44:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Jul 2015 03:44:50 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 12 05:44:41 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZE8C1-00074k-5u for ged-emacs-devel@m.gmane.org; Sun, 12 Jul 2015 05:44:41 +0200 Original-Received: from localhost ([::1]:49652 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZE8C0-00071A-DY for ged-emacs-devel@m.gmane.org; Sat, 11 Jul 2015 23:44:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZE8Bw-000710-2A for emacs-devel@gnu.org; Sat, 11 Jul 2015 23:44:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZE8Bq-000300-Rb for emacs-devel@gnu.org; Sat, 11 Jul 2015 23:44:35 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:47942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZE8Bq-0002z1-KZ for emacs-devel@gnu.org; Sat, 11 Jul 2015 23:44:30 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZE8Bp-0006zy-2Z for emacs-devel@gnu.org; Sun, 12 Jul 2015 05:44:29 +0200 Original-Received: from 222.128.167.57 ([222.128.167.57]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Jul 2015 05:44:29 +0200 Original-Received: from eric by 222.128.167.57 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Jul 2015 05:44:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 64 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 222.128.167.57 User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:CnK7M5iaJ/X4rpL4CzanV3q2niQ= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:187812 Archived-At: Stefan Monnier 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