From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Changing a cl-defstruct definition in a published package Date: Sun, 15 Jul 2018 09:11:05 -0400 Message-ID: References: <9afc36c6-5759-6ea0-4cd4-9d6eb6b073b5@gmail.com> <87601jx6xa.fsf@gmail.com> <8806cd3a-da5f-28da-1aa6-fff611214396@gmail.com> <33b59faf-9357-706e-2239-68411096bc51@gmail.com> <133dfba4-e6c7-3aca-a39f-4d26a688c8b5@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1531660162 7705 195.159.176.226 (15 Jul 2018 13:09:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Jul 2018 13:09:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 15 15:09:18 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fegm6-0001vX-Oz for ged-emacs-devel@m.gmane.org; Sun, 15 Jul 2018 15:09:18 +0200 Original-Received: from localhost ([::1]:45624 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fegoD-00020b-MR for ged-emacs-devel@m.gmane.org; Sun, 15 Jul 2018 09:11:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fego5-00020U-4j for emacs-devel@gnu.org; Sun, 15 Jul 2018 09:11:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fego1-0004Fs-2v for emacs-devel@gnu.org; Sun, 15 Jul 2018 09:11:21 -0400 Original-Received: from [195.159.176.226] (port=38341 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fego0-0004EI-RU for emacs-devel@gnu.org; Sun, 15 Jul 2018 09:11:17 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1feglr-0001ih-BF for emacs-devel@gnu.org; Sun, 15 Jul 2018 15:09:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 42 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:9Z/5j6+X39sUxd4YM8WZXiX8B/Q= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:227425 Archived-At: >> IIUC, outside Flycheck the main operation called (and hence inlined) is >> the constructor(s). Are field accessors also used outside Flycheck? >> If so, is there a chance that they are only ever used on those objects >> that were created by the outside code as well (i.e. those inlined >> accessors only see objects created by the compatible inline >> constructors)? > I don't think so. We have multiple types of extensions, including error > checkers (which create new objects and use accessors on them, then pass them > to Flycheck core which also accesses fields on them) and UI plugins that > take errors produced by the core or plugins and access their fields. Hmm... then it's going to be difficult: old UI plugins will see objects created by the new core, and there's no much we can do at that point, I think. > This might be possible. I will investigate and possibly follow up. > I wonder if there may be a trick to force recompilation of dependencies. > Maybe this is something package.el should support ? There's no doubt that package.el should support recompilation. Patches welcome for that (first to add some code which does the actual recompilation, and then maybe some way to trigger such recompilation of dependencies). > Is there a setting to tell cl-defstruct to not generate macros for > constructors and accessors? Not currently, no. But Joćo would also like to have such a thing. Note that the recompilation issue can be solved outside of package.el: - "recompile package" doesn't have to be in package.el (tho it is its most natural place). - you could have code in flycheck.el that does: (eval-when-compile (dolist (pkg (find-pkgs-using-the-old-flycheck-object-layout)) (recompile-package pkg))) so it will be executed when flycheck is compiled. -- Stefan