unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!)
@ 2013-06-04 22:44 Daniel Hackney
  2013-06-04 23:01 ` Dmitry Gutov
  2013-06-05  1:34 ` plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!) Stefan Monnier
  0 siblings, 2 replies; 24+ messages in thread
From: Daniel Hackney @ 2013-06-04 22:44 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Stefan Monnier, Emacs development discussions

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.

As a result, I'm going to refactor my refactor: I'll make
`package-desc' structures into plists, so that future additions don't
break existing code. I don't think this should be that invasive; all
accesses to `package-desc' structures occur through `package-desc-*'
functions anyway, so not much will change from my current iteration.

What a time to change my mind; I had just finished all of the coding
changes.

Daniel Hackney <dan@haxney.org> wrote:
> Dmitry Gutov <dgutov@yandex.ru> wrote:
>> Any news on this?
>
> I was finishing up on exams, so this had to be put on hold. I'm
> starting up on it again. I think it's close to a mergable state, so
> I'll finish up the NEWS entry and submit the patch for merging.
>
>> I've been holding off on Bug#13291 both because it would complicate
>> the rebase of this changeset, and also because I'd like to use the
>> test harness you have here.
>
> Sounds good. I'll try to get things on my end totally finished so
> development can resume on the new version.
>
>> Daniel Hackney <dan@haxney.org> writes:
>>> I'll do a better job of explaining the whole patch. Should I include
>>> that in some sort of file in the repo or just on the mailing list?
>>> Would a detailed-ish explanation of the changes and rationale be
>>> appropriate for the ChangeLog or NEWS files?
>>
>> You can start with ChangeLog files. When writing a changelog entry,
>> one usually briefly describes and sometimes justifies the mechanical
>> transformations being performed on the code, and it helps other people
>> understand the changes.
>
> Since it is a complete refactoring, what should I say? Should I include
> a line for each new or changed function, or simply refer people to the
> NEWS file?
>
>> I see you've also already started on NEWS entries.
>
> How does it look so far? Any suggestions on how to improve it?
>
>>> About package-x.el, is the HTML and RSS updating functionality actually
>>> used? Currently, the only way to access the functionality is calling
>>> `package-maint-add-news-item' or the non-interactive
>>> `package-upload-buffer-internal' directly. GNU ELPA clearly doesn't use
>>> the version in package-x.el, as the HTML generated is not what
>>> package-x produces.
>>
>> Probably not. Melpa and Elpakit don't seem to be using it either.
>>
>>> Can I consider it unused and delete it? If not, I'll refactor it with
>>> the rest of the code.
>>
>> Personally, I'd delete them, but that's not my call. Maybe decorate them
>> with FIXMEs, leave them unfixed and see if anyone complains up until the
>> pretest?
>
> I did some porting and they should continue to work, although they don't
> do much of anything useful, just like before.
>
> One other change I made, which probably deserves some discussion, is
> that I created a folder "test/automated/data" which is intended to hold
> test-related data. I created a subfolder "package" (so it is
> "test/automated/data/package") which contains a test "archive-contents"
> file, as well as test elisp files. My hope is that such a directory
> could be useful for other tests which need example data.
>
> I also added a rule in the "Makefile.in" to skip byte-compilation of the
> files in "data".
>
> --
> Daniel Hackney



--
Daniel Hackney



^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2013-06-10  4:00 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-04 22:44 plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!) Daniel Hackney
2013-06-04 23:01 ` Dmitry Gutov
2013-06-05 14:53   ` Ted Zlatanov
2013-06-05 17:41     ` Stefan Monnier
2013-06-05 17:56       ` Drew Adams
2013-06-05 18:06         ` Ted Zlatanov
2013-06-06  9:30           ` Stephen J. Turnbull
2013-06-06 12:51             ` Ted Zlatanov
2013-06-07  3:07               ` Stephen J. Turnbull
2013-06-07 13:03                 ` opaque data types (was: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!)) Ted Zlatanov
2013-06-07 13:27                   ` opaque data types Christopher Schmidt
2013-06-07 14:11                     ` Ted Zlatanov
2013-06-07 15:44                       ` Christopher Schmidt
2013-06-07 16:01                         ` Ted Zlatanov
2013-06-08  9:19                           ` Christopher Schmidt
2013-06-10  3:56                             ` Ted Zlatanov
2013-06-07 16:17                   ` Stefan Monnier
2013-06-07 17:48                     ` Ted Zlatanov
2013-06-08  6:11                   ` Stephen J. Turnbull
2013-06-08  6:28                   ` opaque data types [revise and resend] Stephen J. Turnbull
2013-06-10  4:00                     ` Ted Zlatanov
2013-06-05  1:34 ` plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!) Stefan Monnier
2013-06-06  1:31   ` Daniel Hackney
2013-06-08  6:47     ` Rand User

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).