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

[Rand User]

> From: Daniel Hackney <address@hidden>

> To: Stefan Monnier <address@hidden>
> Cc: Emacs development discussions <address@hidden>; Dmitry Gutov 
> <address@hidden>
> Sent: Wednesday, June 5, 2013 8:31 PM
> Subject: Re: plist-based package.el (was Re: cl-defstruct-based package.el,
        now with ert tests and no external tar!)
> 
> 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 structures saved/loaded from files are the ones returned from the package 
servers, right?  Aren't these the ones that need to be flexible for 
extensibility?

Right now, the structures returned from the servers  basically consists of an 
alist of package symbols consed to package-desc vectors.  e.g.

(lex .
      [(1 1)
       nil "Lexical analyser construction" tar])

My suggestion would be to change the format of the data returned from the 
servers to something that allows arbitrary key-data pairs.  define-package 
should then allow package authors to specify arbitrary values that are passed 
along by the server.

Cheers,
Rand