From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hackney Newsgroups: gmane.emacs.devel Subject: Re: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!) Date: Wed, 5 Jun 2013 21:31:53 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1370482338 7809 80.91.229.3 (6 Jun 2013 01:32:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Jun 2013 01:32:18 +0000 (UTC) Cc: Emacs development discussions , Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 06 03:32:21 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UkP3t-0000jN-5M for ged-emacs-devel@m.gmane.org; Thu, 06 Jun 2013 03:32:21 +0200 Original-Received: from localhost ([::1]:57249 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkP3s-0000ig-PN for ged-emacs-devel@m.gmane.org; Wed, 05 Jun 2013 21:32:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkP3o-0000iO-OC for emacs-devel@gnu.org; Wed, 05 Jun 2013 21:32:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UkP3n-0004We-MA for emacs-devel@gnu.org; Wed, 05 Jun 2013 21:32:16 -0400 Original-Received: from mail-ie0-x22f.google.com ([2607:f8b0:4001:c03::22f]:34322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkP3n-0004WX-By for emacs-devel@gnu.org; Wed, 05 Jun 2013 21:32:15 -0400 Original-Received: by mail-ie0-f175.google.com with SMTP id a11so5420145iee.6 for ; Wed, 05 Jun 2013 18:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=haxney.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pAsNVCCYx9lll/U4dcjL0bfpkwFyTWEvsz+iD8ly0Kc=; b=Wjgkvvvfm5GIf2yVaP/rU1e/KvM4PUNa7PMd2qb3o6j3Gtn6Goh8K5l29rdsjolzLr yJSKU+/6k16Z6Dr5+keiToWchKzbgpLiCd8GoZuhgdBTzKW2vszqC8C5udIYOJWHoqpb Te33kECB+QbhRzx6FHoSc55KZCReZ9PRW4mWs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=pAsNVCCYx9lll/U4dcjL0bfpkwFyTWEvsz+iD8ly0Kc=; b=o35wlOydqDXQcVNxp5iXKdlJ4x2QB0nf6r2UOu8lSfcD42Nz1WbfVkPfYXWh6KpArw nR2eUT7wtClWjzfMqgd4/b3uieZDwsfz7xtrYKBvxY0xVoPTpGkSwIOVjp4lGSCOyjyL esZDjE9cdpVMnByhLNgryTVyLoHBcl1eUUHVj38kdHE3obIZu6aKyrf57+9c1h2aKoiI fQCb6+kfRy6sLQaOjQA0ktPLANVtdtw4MwQW+aF7hxJAEUVdZuRyjhIm1buJOGS89Kog pm7Dgm7LOt31kyLfjgYD3uNk2jWtwQJgZz9zvniBc011hhACy5+Zvqv7IORW6UmBHrMC NLqw== X-Received: by 10.50.28.78 with SMTP id z14mr4514834igg.26.1370482334103; Wed, 05 Jun 2013 18:32:14 -0700 (PDT) Original-Received: by 10.64.246.194 with HTTP; Wed, 5 Jun 2013 18:31:53 -0700 (PDT) In-Reply-To: X-Gm-Message-State: ALoCoQlBr6fDf4fi9USLBGS129MdI1K6YoZ0LR2CnvAd0GYKcCbGwcnhUNojy0NsQlLKoJVJNZ2o X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:160154 Archived-At: Stefan Monnier 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 only exception to that is in "finder-inf.el", though I could change that. My thought was that package.el could be made extensible with things like hooks and extended properties, so functionality could be added by adding some functions to `package-install-functions' or somesuch. That way, adding, for example, digital signature checking could be done by creating a property :sig on the `package-desc' structure and adding some checks to package installation hooks. That may be getting ahead of myself, though. I did finish the `cl-defstruct' -> `plist' transition. It was little more than creating `defsubst' and `gv-define-setter' calls for each property and regenerating "finder-inf.el". -- Daniel Hackney