all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Eric Abrahamsen <eric@ericabrahamsen.net>
Cc: emacs-devel@gnu.org
Subject: Re: Turning Gnus groups into real objects
Date: Thu, 18 Jul 2019 13:59:49 +0200	[thread overview]
Message-ID: <87wogf8sei.fsf@mouse.gnus.org> (raw)
In-Reply-To: <87k1cg5ujl.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Wed, 17 Jul 2019 12:29:34 -0700")

Eric Abrahamsen <eric@ericabrahamsen.net> 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



  parent reply	other threads:[~2019-07-18 11:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-17 19:29 Turning Gnus groups into real objects Eric Abrahamsen
2019-07-17 21:33 ` Andy Moreton
2019-07-17 22:04   ` Eric Abrahamsen
2019-07-17 21:59 ` Stefan Monnier
2019-07-17 22:08   ` Eric Abrahamsen
2019-07-18 11:59 ` Lars Ingebrigtsen [this message]
2019-07-18 18:01   ` Eric Abrahamsen
2019-07-19 12:56     ` Lars Ingebrigtsen
2019-07-19 18:47       ` Eric Abrahamsen
2019-07-19 22:10         ` Stefan Monnier
2019-07-19 23:56           ` Eric Abrahamsen
2019-07-20 12:52         ` Lars Ingebrigtsen
2019-07-21  1:41           ` Eric Abrahamsen
2019-07-21 12:34             ` Barry Fishman
2019-07-22 17:14               ` Eric Abrahamsen
2019-07-21 13:40             ` Stefan Monnier
2019-07-22 16:38               ` Eric Abrahamsen
2019-07-21 14:02             ` Lars Ingebrigtsen
2019-07-22 16:26               ` Eric Abrahamsen

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=87wogf8sei.fsf@mouse.gnus.org \
    --to=larsi@gnus.org \
    --cc=emacs-devel@gnu.org \
    --cc=eric@ericabrahamsen.net \
    /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.