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

[Dmitry Gutov]

On 05.06.2013 2:44, Daniel Hackney wrote:
> Looking at Bug#13291 ("The package description buffer needs an URL
> 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")
>
> This is desirable for structures which don't change, but we are going
> to want all sorts of extra slots in `package-desc' structures.

I haven't had the time to read your patch properly yet, but I don't 
think that's necessarily true. Just like I did in my current patch for 
#13291, one of the fields in the struct can contain an alist with all 
extra properties.

Setting their values would be a tad less convenient, I suppose, but for 
getters, for example, `package-desc-homepage' can be a plain function, 
delegating to (cdr (assoc :homepage (package-desc-extras desc))).

Or with a more dynamic approach: (package-desc-extras-get :homepage). 
The implementation would also be simple.

Just an option to consider.