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

[Stefan Monnier]

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


        Stefan