Superclass not correctly initialized in modules with circular dependencies

[livelykernel]

Superclass not correctly initialized in modules with circular dependencies

[rksm]

Actually, "forward declaration" might not even be enough, classes might need to become functions again that get hoisted... b/c of the way that SystemJS / System register modules declaration work...

[rksm]

Also note that when changing the order of imports in test from a.js, b.js to b.js, a.js there isn't a problem b/c dependent modules get run first, so a.js defines Foo before reaching the definition of Bar.

[rksm]

I have played around with various solutions like falling back to normal function declarations for classes but this breaks the expected class behavior / es6 class specification. It looks like this is a real conceptual issue with es6 and others have observed that as well [1] and I was able to reproduce it with a vanilla systemjs / babeljs setup.

As stated in [1], the availability of class definitions depends on the module import order... reloading a cuple of times until it works... it can't get much more ugly than that. Anyway, I will close this issue for now as I'm not able to find a solution that would be compatible with es6 classes :/

[1] systemjs/systemjs#1209

[rksm]

And down the rabbit hole... This issue kept bothering me b/c it would prohibit pretty basic usage of modules and top-level classes. For an example consider the BoundsMarker in lively.morphic/markers.js. It is a morph that inherits from the Morph class, yet the module is itself imported by the morph.js module b/c it defines additions (show function) that should be available for morphs in general. The issue caused BoundsMarker to be incorrectly initialized (it inherited from "undefined" = Object instead of Morph), breaking its behavior.

I can easily imagine lots of similar scenarios in packages that would repeatedly cause very hard to track issues. For that reason I decided to implement around the es6 / System.register specification. When using Lively es6 class definitions that get generated from generic es6 class syntax, we pass in the module context the class is defined in + statically available information about the superclass (it's name / reference). With this information we are able to subscribe to changes in the internal module runtime state. This allows us to update the class definition with new superclasses from other modules when the superclass binding changes. Practically "extending the reach" of module bindings. Thus, the problem mentioned above is solved. Downside: Lot's of machinery is necessary to make this work...

[levjj]

It seems that this solution would work for now. However, I think there are two disadvantages. There could be another solution but I don't know yet whether this works.

1. Storing additional meta-information to class definitions in Lively could be useful for debugging but if we add too much functionality here, this would not work well with non-Lively class definitions. For example, you could think of using a class definition defined in an external JavaScript file and using it as superclass for a Lively class. For now we can probably rewrite all of these before loading but there could be browser built-in APIs that use classes in the future. Again, storing a reference to the module for debugging is still useful but relying on the fact that all classes are always Lively es6 classes could bite us back in the future.
2. The approach only subscribes to changes to top level definitions. I wonder whether this could cause problems if the class definition is somewhat indirectly given. So, in the following example, if you change a.js (or load it for the first time), does this also change (or initialize) the superclass of B?

// a.js
import {B} from "b.js";

export class A { m() { return new B(); } }

// geta.js
import {A} from "a.js";

export function getA(n) { return A; }

// b.js
import {getA} from "geta.js";

const A = getA();

export class B extends A {}

Idea: This is just an idea and it may not work in practice but I don't yet see why it would be impossible to determine the right loading order just before loading module with classes and importet superclasses. As you pointed out, loading 'b.js' and then 'a.js' works fine. Maybe this is too much work or does not work for other reasons but maybe the "right" order could be determined simply by parsing the module and swapping the order before loading.

[rksm]

1. So far this only affects the runtime and we need to instrument that anyway, otherwise a modification of class would always result in a new class instance and not modify the existing one.

2. No, metadata is attached to all classes, even anonymous, so this mechanism should work just fine.