Lazy definitions

[rksm]

Entities in the top-level such as class and object definitions currently get re-defined on moduleSourceChange and reloadModule operations. Often modifications of those objects that keep the original identity reflect the users intentions better.

• identify objects whose identity should be maintained
• for those objects, implement an update strategy*
• use those updates via options, e.g. options.resetEnv = false in reloadModule could signal to keep objects, maybe a more explicit behavior is better

*The tricky part are deleted sub-elements such as methods and properties for classes. Given that an object or class can be extended in multiple places, we cannot simply remove all props/methods that don't occur in the latest class / obj definition. What's needed is to track the location of these sub-elements and compare them with the location of the re-definition to figure out if a prop/method should be removed.

[rksm]

When capturing code with options.keepPreviouslyDeclaredValues = true we will lazy initialize objects and classes, maintaining their identity when they already exists. The policy for that is currently implemented in lively.ast.evalSupport.declarationWrapperForKeepingValues.

Note: We currently DO NOT remove elements that don't appear in the definitions anymore. So when you first evaluate class Foo { m() {} } and then class Foo {}, Foo will still have a method m! Since this should work for most cases I will leave this as an open item with low priority for now.

[rksm]

Keeping identity for arbitrary objects turned out to be confusing. We keep classes around via initializeClass. The declaration wrapper still exists and might be useful for other hooks but if we don't find any it will be removed in the next version.

[levjj]

I would also be in favor of actually removing methods and accessors from classes when the class definition changes. It may seem like an edge case but there have been multiple confusing situations caused by out-dated methods and accessors being called after renaming them in the class definitions. This could also cause problems with a method got deleted with the intention of calling the superclass. In that case, leaving the out-dated method prevents the super call.

This could be problematic if classes could be extended but as long as there are no mixins, it should be fine.