User:Colby Russell/Static initializers

Since static initializers aren't allowed in the triple script dialect, what about making way to use selective reification as an easy substitute?

One example is in ZodLib, where we don't pre-compute the CRC-32 table, which almost certainly leads to performance degradation that wouldn't be a problem if we had static initializers.

On the other hand, people go crazy with every affordance being used in the most ill-advised ways, and static initialization is a top recurring problem. Maybe we can finesse the dialect/ecosystem in such a way that people perceive selective reification to be too heavyweight to be used as casually as it is static initialization shows up in, say, Java, JS, Oberon, Go, etc.

Highly relevant to some notes I took yesterday:

Right now, we say that there is a prohibition on global shared state, but at the same time, we allow the browser and NodeJS layers to cheat—through guarded access following a successful typeof check, but it's still cheating. This seems to be privileging the host platforms over well-behaved modules. I can never write an orinary module, for example, to do "global" mutations on shared state. Maybe we do need a way to allow for this, but still mandate that this only occur in the host layers. (Do we need some provision in the dialect to annotate this stuff?) Or maybe we can just defer to treason + selective reification? (Is that just hand waving things away?) In my notes, I have been floating the idea of doing namespaces by fixing them up into classes and autogenerating a constructor. Maybe there's a good anchor point there for this, too. XXX Gilad keeps calling these "aliens" in the Channel 9 video about Newspeak.

---

2020 July 06: Okay, so thinking about this more, it seems like there's a pretty clean way to do this with selective reification, by establishing an activation protocol. This can wait for the work on treason first, but in principle, different runtimes can establish their own activation protocol.

(Side note: Yesterday I came to the conclusion that the kind of annotation mentioned above is essential. Viz $unsafe$.)

Here's one sketch of how an activation protocol can work:

Lifecycle includes with two phases:

• Awaken
• Explicit activation (if requested)

The runtime manages the awaken phase, with the shunting block detecting/responding to some "ambient" symbol, which can be used to establish communication. If explicit activation is desired, the bundle can use this channel to send a message requesting such activation, which the environment will dispatch to the bundle at the appropriate time. Request for activation can also be accompanied by the name of the bundle's own symbol that will handle activation (defaulting to an activate function otherwise). The activation handler when called will itself get a direct reference to some messaging facilitator as its argument (called post by convention).

The initial specially-defined symbol can be something as simple as a Treason global (which the shunting block finds by way of an explicit typeof check) followed by ambient instantiation of Treason.Post objects. (The post facilitator that the activation handler receives will just be a fancy wrapper for these Post ("Message"?) instances.)

In the general case, this can also be used to control things like lifetimes, module persistence, whether or not (e.g. in the case of sepsis-inspector) the viewer would like to be initialized in a new context. This would be a general solution to the suppliers-and-synth-blocs and module.singleton hack that I originally implemented in sepsis-inspector's RequireJS/CommonJS-like module loader. What's really nice is the _same_ activation protocol can be used for viewer registration—we don't need such things as bindings to the XPCOM category manager (and of course we've already obviated the dubious JSON schema-based design I originally came up with). For example, to install a new viewer, you either drag its bundle into the window, or point the Inspector at its URL, and it does a similar dance to awaken the bundle and the bundle begins sending messages to control/facilitate installation.

I particularly like the ambient Post instantiations during awakening. It hews closely to Alan Kay's biological metaphor of objects as cells. The bundle's concern is only with manufacturing the appropriate products, in response to some stimulus, but then otherwise sets them adrift without worrying about where to send them. (The overall environment is responsible for making sure they end up at the right place, and in our case of course we make sure that this process is deterministic rather than a crapshoot—after all, it wouldn't be very attractive if we were only promising a chance that the thing the user wants to happen actually ends up happening.)