[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: plist-based package.el (was Re: cl-defstruct-based package.el, now w
From: |
Rand User |
Subject: |
Re: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!) |
Date: |
Fri, 7 Jun 2013 23:47:54 -0700 (PDT) |
> 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
- Re: opaque data types, (continued)
- Re: opaque data types, Stefan Monnier, 2013/06/07
- Re: opaque data types, Ted Zlatanov, 2013/06/07
- opaque data types, Stephen J. Turnbull, 2013/06/08
- opaque data types [revise and resend], Stephen J. Turnbull, 2013/06/08
- Re: opaque data types [revise and resend], Ted Zlatanov, 2013/06/10
Re: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!), Stefan Monnier, 2013/06/04