Re: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!)

[Daniel Hackney]

Stefan Monnier <address@hidden> wrote:
>> button"), I'm having a crisis of confidence in my plan to use
>> `cl-defstruct' to represent `package-desc' structures. The big problem
>> with `cl-defstruct' in this case is its lack of extensibility. We are
>> going to want to add additional slots to `package-desc' structures over
>> time, but doing so would require redefining `package-desc' each time.
>> `cl-defstruct' requires that structures be of the exact length given in
>> the definition of the structure; if, for example, `package-desc-name'
>> gets a vector with an unexpected length, it will signal an error:
>
>>     (error "package-desc-name accessing a non-package-desc")
>
> I don't see the relevance: those defstruct structures should be internal
> to package.el (i.e. never saved to a file or loaded from a file), so
> there's no risk of using one with the functions of another.

The only exception to that is in "finder-inf.el", though I could change
that.

My thought was that package.el could be made extensible with things
like hooks and extended properties, so functionality could be added by
adding some functions to `package-install-functions' or somesuch. That
way, adding, for example, digital signature checking could be done by
creating a property :sig on the `package-desc' structure and adding
some checks to package installation hooks.

That may be getting ahead of myself, though.

I did finish the `cl-defstruct' -> `plist' transition. It was little
more than creating `defsubst' and `gv-define-setter' calls for each
property and regenerating "finder-inf.el".

--
Daniel Hackney