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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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