From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Turning Gnus groups into real objects Date: Thu, 18 Jul 2019 13:59:49 +0200 Message-ID: <87wogf8sei.fsf@mouse.gnus.org> References: <87k1cg5ujl.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="22424"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 18 14:00:01 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 1ho54q-0005bm-NO for ged-emacs-devel@m.gmane.org; Thu, 18 Jul 2019 14:00:00 +0200 Original-Received: from localhost ([::1]:36866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1ho54p-0005na-PE for ged-emacs-devel@m.gmane.org; Thu, 18 Jul 2019 07:59:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60658) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1ho54n-0005nG-9V for emacs-devel@gnu.org; Thu, 18 Jul 2019 07:59:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ho54m-0007GI-31 for emacs-devel@gnu.org; Thu, 18 Jul 2019 07:59:57 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:58458) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ho54l-0007DP-Sb for emacs-devel@gnu.org; Thu, 18 Jul 2019 07:59:56 -0400 Original-Received: from [80.169.244.84] (helo=sandy) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ho54g-00053y-3h; Thu, 18 Jul 2019 13:59:52 +0200 In-Reply-To: <87k1cg5ujl.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Wed, 17 Jul 2019 12:29:34 -0700") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 80.91.231.51 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:238638 Archived-At: 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. > 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. > 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. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no