Re: Changing a cl-defstruct definition in a published package

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2460 bytes --]

On Thu, Jul 12, 2018, 21:13 Clément Pit-Claudel <cpitclaudel@gmail.com>
wrote:

> Hi all,
>
> I'm sure this has already been discussed, but I couldn't find the relevant
> discussion.  I'm running into issues trying to update a package without
> breaking other packages that depend on it.  Advice would be very welcome.
>
> 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?
>
> Thanks!
> Clément.
>

Hi Clément,

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.

João

[-- Attachment #2: Type: text/html, Size: 3445 bytes --]