Re: Turning Gnus groups into real objects

[Eric Abrahamsen]

Lars Ingebrigtsen <address@hidden> writes:

> 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.

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