From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Turning Gnus groups into real objects Date: Thu, 18 Jul 2019 11:01:00 -0700 Message-ID: <87zhlb2per.fsf@ericabrahamsen.net> References: <87k1cg5ujl.fsf@ericabrahamsen.net> <87wogf8sei.fsf@mouse.gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="235330"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 18 20:01:26 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hoAiY-000z3t-U4 for ged-emacs-devel@m.gmane.org; Thu, 18 Jul 2019 20:01:23 +0200 Original-Received: from localhost ([::1]:40136 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hoAiW-0000ml-Jq for ged-emacs-devel@m.gmane.org; Thu, 18 Jul 2019 14:01:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36765) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hoAiT-0000mQ-KO for emacs-devel@gnu.org; Thu, 18 Jul 2019 14:01:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hoAiS-0001yi-5w for emacs-devel@gnu.org; Thu, 18 Jul 2019 14:01:17 -0400 Original-Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:39230 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hoAiR-0001x1-VO for emacs-devel@gnu.org; Thu, 18 Jul 2019 14:01:16 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hoAiM-000ypq-7Y for emacs-devel@gnu.org; Thu, 18 Jul 2019 20:01:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:Om4I28I8YtO6WDuw5UBDkoMJCew= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.emacs.devel:238687 Archived-At: Lars Ingebrigtsen writes: > Eric Abrahamsen writes: > >> Group infos are manipulated using a series of `gnus-info-*' getter >> macros (starting line 2797 in gnus.el), with a corresponding series of >> `gnus-info-set-*' setter macros, though the setters are used less often. >> In fact, quite a bit of the Gnus code ignores the getters/setters >> altogether, and manipulates the info lists directly (with code like >> "(setcar (nthcdr 3 info)...)", etc). > > Fixing up that (and using setf instead of info-set-*) would be nice. Okay, I'll continue that work. >> So I thought a good first step would be to regularize the code so that >> it only uses the accessors to touch group data, making it easier to >> later change the underlying implementation. But this is going to involve >> a fair amount of personal preference. >> >> First of all, I'd love to get rid of the group/info/entry distinction, >> and only have "groups" (plus "group-name", if we have to refer to the >> string name). So the accessors would be named "gnus-group-*" instead of >> "gnus-info-*". > > The "group" thing is already a very overloaded concept. "gnus-group-" > function refer to the gnus-group-mode, for the most part. I think it > makes more sense to just keep the "info" concept. I mean, a "group > object" could equally well refer to the state of the info in a summary > buffer, for instance. I'm totally fine with that, but if we're not able to change the underlying data structures, it's mostly a moot point -- we're still going to need group vs info vs entry. >> When defining classes, a slot can have a :reader tag and a :writer tag, >> or an :accessor tag that does both. So for example the current code >> would look like: >> >> (defclass gnus-group () >> ((marks >> :type list >> :initform nil >> :writer gnus-info-set-marks >> :reader gnus-info-marks) >> ...)) > > As for using cl-defstructs for the group infos -- I don't think that's > realistic. The most important reason is that (as you've noted) a lot of > the code don't use the setters and getters. That can be fixed in-tree, > but people all around the world have code out-of-tree that accesses > those things. The design of those data structures have basically not > changed, only been extended, since around 1987. > > The other reason is that people do have tens of thousands of groups, > especially the few that are still using NNTP servers. Getting from the > serialised format to the in-memory Gnus structures (but the info and the > group entries) uses (probably) fastest path possible. This conversion > into another data type will probably make startup significantly slower > for these users. Well... bummer. I guess I still feel that any additional slowdown in startup could be offset by speedups elsewhere, but if we want to keep that level of backward compatibility, there's not much else that can be done. My original long-term plan was to replace the nnoo machinery with Emacs' built-in object stuff: defvoo would become object slots, and deffoo would become generic functions. Would this be a bad idea for the same reason? That would also be a bummer, but at the same time save me a lot of work :) Thanks, Eric