From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Re: Changing a cl-defstruct definition in a published package Date: Fri, 13 Jul 2018 20:38:20 +0300 Message-ID: <87lgaf3uk3.fsf@tcd.ie> References: <9afc36c6-5759-6ea0-4cd4-9d6eb6b073b5@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1531503516 4854 195.159.176.226 (13 Jul 2018 17:38:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Jul 2018 17:38:36 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel , emacs-devel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 13 19:38:32 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 1fe21V-00019i-Of for ged-emacs-devel@m.gmane.org; Fri, 13 Jul 2018 19:38:30 +0200 Original-Received: from localhost ([::1]:38559 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fe23c-0002aZ-U5 for ged-emacs-devel@m.gmane.org; Fri, 13 Jul 2018 13:40:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fe21W-0001E6-SC for emacs-devel@gnu.org; Fri, 13 Jul 2018 13:38:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fe21R-0003K3-Vw for emacs-devel@gnu.org; Fri, 13 Jul 2018 13:38:30 -0400 Original-Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]:43525) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fe21R-0003G2-NP for emacs-devel@gnu.org; Fri, 13 Jul 2018 13:38:25 -0400 Original-Received: by mail-ed1-x52d.google.com with SMTP id u11-v6so25169251eds.10 for ; Fri, 13 Jul 2018 10:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-transfer-encoding; bh=djRZSrnCZ5/iNFw3idvVZqnnFD5TLXKkLn8HkS12DVE=; b=pejHr+icL0PyEeMfz5m2Vh8w3fOfrmMGwTxYuFSQN3Zc+uvOgYLzZ5W0y8YPzxXNy6 1VKHR3k5AbBR2YH+6PqIPfdnHiiKQM0UzeRZZG+ageTPJFqksuk/4L0BDhkiTW2tdYb7 arzMhvV7PcKjnPMdEjeI3uhmfL6r8wdezrpV81j1Olici3vvM8XPxlddbgKDoFKiDRCN /EgwRFM0vpT/46OQkk6pMbobIMLcaw48n0PRcMPEmPajkJXNyu+/jdIh2qpFwPvSDnTN I23emIU5o2T97M8yLml7sRSSVKJFSWP1mnc1Ko0xrMUEnlTZcqzATbT4eTlj0zBqTs+g hDIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:message-id :user-agent:mime-version:content-transfer-encoding; bh=djRZSrnCZ5/iNFw3idvVZqnnFD5TLXKkLn8HkS12DVE=; b=uWajVundOWoM/MSKbRaqsEdCrVUZC16DX1vmJpFsFaTrtBxUIgbsSVEmbOm2Yg+5q0 H9JmpP1WrJ5MhMyjvDZcuj9W3QNErukd5tI1PglmHRVhFdZAv5VY9mrOyY3hy0WRtLP7 Pcjp5EQCvDHjIvAVtqKZAR5Q4nsgY55T31MX67qESrdDUtWEiWN3Tk+/JeFesGeRUo4L 69+NO5aEH5iIFcsOV36x4DE16hulAG3V4hUUNMZq8tIfBuhG2mMPhAxBNhA0uDIrEKuP CmpJdMrZAOtyL+eRZGRBNzbX2NSPec48+X3H1EnWkn/nQGKwI7+8IjMI4eOlxXuk+IeT CjzQ== X-Gm-Message-State: AOUpUlEaHMojNpp+NpERBRjoIzaGJCzCGCgPS9UXZM7m9Hh34Anf+7aA ZJGXlhvWLcik1amtuntVqH3DmA== X-Google-Smtp-Source: AAOMgpfzZGvr3WwuBHFobIi7w/XgQMA2RycBKcVtMxoce7QUbbmQpZ2jEzrxjxvHcDyr7RR5uwe4ew== X-Received: by 2002:a50:8818:: with SMTP id b24-v6mr8329768edb.274.1531503503691; Fri, 13 Jul 2018 10:38:23 -0700 (PDT) Original-Received: from localhost ([213.233.149.25]) by smtp.gmail.com with ESMTPSA id d34-v6sm2044449edd.58.2018.07.13.10.38.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 13 Jul 2018 10:38:23 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::52d 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:227357 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > On Thu, Jul 12, 2018, 21:13 Cl=C3=A9ment Pit-Claudel wrote: > >> I maintain package A, which contains this: >> >> (cl-defstruct aaa-info >> line message) >> >> (provide 'aaa) >> >> Someone else wrote a package B that contains this: >> >> (require 'aaa) >> >> (defun bbb-print-message (info) >> (message (aaa-info-message info))) >> >> (provide 'bbb) >> >> Users have installed both packages through package.el. I update A >> by adding a new field to the definition of aaa-info, and push the >> update to ELPA or MELPA: >> >> (cl-defstruct aaa-info >> line column message) >> >> Users update using package.el, but this does not cause b to be >> recompiled. From this point on, any subsequent call to >> bbb-print-message to bbb-print-message fails: for example, >> (bbb-print-message (make-aaa-info :line 1 :column 2 :message "XYZ")) >> prints this: >> >> Debugger entered--Lisp error: (wrong-type-argument stringp 2) >> message(2) >> bbb-print-message(#s(aaa-info :line 1 :column 2 :message "XYZ")) >> >> Similarly, if I update the constructor of aaa-info to give the new >> 'column' field a default value, instances created by the >> previously-compiled B will still be missing the 'column' slot, >> leading to all sorts of errors. >> >> What is the recommended way to change a cl-defstruct definition >> without running into these issues? > > There's no way to fix the problem now without breaking backward > compatibility because by now B's use of your accessor has been > compiled into something that probably looks like an aref into an > array. So if you change your object layout in A, you break a compiled > B. > > The way to avoid this beforehand is not to expose the defstruct's > accessors as a public interface. You can't think of them as > functions, because they have compiler macros associated. The easiest > "solution" now is to make proper functions for those accessors that > are public, and then having B recompiled. Also consider if you really > need defstructs for their speed, because they're usually an array in > disguise. Perhaps a (slightly, in most cases) slower eieio class > would do. If cl-defstructs boil down to an array in disguise (I don't know because I've never looked into them), would appending (as opposed to prepending or inserting) new slots maintain backward compatibility? E.g. going from: (cl-defstruct aaa-info line message) to: (cl-defstruct aaa-info line message column) instead of: (cl-defstruct aaa-info line column message) (despite my finding the latter aesthetically nicer, as it groups line and column together). --=20 Basil