emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Turning Gnus groups into real objects


From: Lars Ingebrigtsen
Subject: Re: Turning Gnus groups into real objects
Date: Thu, 18 Jul 2019 13:59:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eric Abrahamsen <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]