Technical: loading packages

Hello!

This is a bit technical mail about inner parts of Amber. It looks like
current way of loading packages hits its limits / needs to be fixed
(https://github.com/amber-smalltalk/amber/issues/1197). I'd like to hear
what you think of possible ways out.

At the moment, when the package is loaded [1], it contains a "compiled
file-in"; that is, it contains series of direct calls to Amber API like
addClass and addMethod. That means, new classes and method are added
eagerly to Amber at the point when package is loaded. Classes are
already part of Amber at that point (are accessible via Amber globals),
even if they were not initialized (wired into hierarchy and performing
FooClass >> initialize calls). That happens later (in case of initial
loading of an app, you do it yourself in loader callback by calling
`amber.initialize({...options...})`.

   define("foo/bar", [...], function () {
     ...
     $core.addClass(..., $globals.SuperClass, ...);
     $core.addMethod(..., $globals.TheClass);
     ...
   });

This system has a few weak points, especially when considering
late-loading of packages. The two main concerns are: what if
initialization does not happen (the issue mentioned above), or, what if
error happens, either during loading or during initialization. Amber can
be left in inconsistent state.

What I think should be the goal if Amber could load packages in
transaction - either everything is in or nothing.

I see two ways of it. First is if package would just create the objects
(classes, extension methods, metadata) and exported them. Nothing would
be _mutated_ in the system; but then, something (Amber bootsequence and
dynamic late-loader) would need to be explicitly instructed to
initialize and adopt the package payload. In case of initial load it is
probably doable with little changes, though it is just a guess.

   define("foo/bar", [...], function () {
     var classes = [], methods = [];
     ...
     var TheClass = $core.class(..., $globals.SuperClass, ...);
     classes.push(TheClass);
     methods.push($core.method(..., TheClass));
     ...
     return {classes: classes, methods: methods, ...};
   });


Or maybe Nicolas had a reason behind it and would like to retain the
package as (figuratively) a function from one Smalltalk state to
another, even if it is (de facto) mutator of Smalltalk itself. In that
case, maybe it would be just enough to wrap the existing thing in a
factor function, which them must be called explicitly (by initial or
late loader).

   define("foo/bar", [...], function () {
     return function($core, $globals) {
       ...
       $core.addClass(..., $globals.SuperClass, ...);
       $core.addMethod(..., $globals.TheClass);
       ...
     };
   });

Though, to be able to recover from errors, this second way must employ
some isolation decorators, anyway, IMO; but looks more like
dependency-injection, especially when it would be like

   define("foo/bar", [...], function () {
     return function($core, SuperClass, ...) {
       ...
       var TheClass = $core.addClass(..., SuperClass, ...);
       $core.addMethod(..., TheClass);
       ...
     };
   });

All the new approaches need more explicit work with the packages
instatiation, but allow more control over the process; the existing
process just installs them while loading, but there is less control then.

Thoughts?

Thanks, Herby

[1] As an AMD module, but that does not really matter to the discussion;
it was same as when it was loaded as just a <script> pre-0.12, sans
automatic load-dependency-ordering.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Herby Vojčík wrote:
> case, maybe it would be just enough to wrap the existing thing in a
> factor function, which them must be called explicitly (by initial or

factory

> late loader).

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.