Update instances when class definition changes after module reload

[levjj]

When using modules in workspaces such as in the example below, changes to the foo method are automatically applied to the instance a in the second workspace when evaluating the whole workspace content.

However, this does not work when just working with modules. In particular, the combination of moduleWrite and reloadModule only reloads modules that depend on the updated module but instances of classes will still use the old method definition.

As a workaround, it is possible to simply re-evaluate the entire module with lively.vm but it seems this should happen automatically with reloadModule.

[rksm]

reloadModule can keep the identity of objects when you tell it to keep its environment via passing options. However we specifically do not need to reload modules when we save them. Particularly for the purpose of commiting a module change we have the moduleSourceChange method that should be used from within a tool via system. interactivelyChangeModule. This method uses a mechanism that ensures the identity of classes and exports and will properly update the instances of your classes.

[levjj]

Okay, this would probably solve the issue. However, the method interactivelyChangeModule can only be used by the vmEditor (or tools with a method updateModuleList) due to this line:

await vmEditor.updateModuleList();

Instead, I would suggest to use notifications, so tools can subscribe to "moduleChange" and similar events. With the current implementation , other tools or multiple instances of the vmEditor are not supported (with multiple vmEditors only one will update, leading to an inconsistent state).