User:Colby Russell/Composability: Difference between revisions
details of a third composability problem
m (describe these concerns as unsolved) |
(details of a third composability problem) |
||
Line 25:
attempts to do its own chainloading internally. This is less than ideal that
the "reified pipelines" approach described above.)
----
'''2021 November 01''': Consider a third composability problem that is solved in Newspeak but not with triple script modules: we want to allow visualization of a program (say a compiler) with interactive diagrams and/or inspectors, and we opt to do this by subclassing the original components in order to constrain necessary changes to a separate "layer" that doesn't interfere in the vein of cross-cutting concerns with the original implementation. Subclassing *is* well-suited for this problem, except in one area: tight binding by name for dependency on another module.
Consider a parser and tokenizer for example, implemented by the classes `FooParser` and `FooTokenizer`. It may be the case that `FooParser` is implemented such that it is never responsible for instantiating the associated tokenizer, instead having it passed in at the constructor or later with the use of some other method, but it is also possible that `FooParser` will indeed attempt to manage its own tokenizer by importing `FooTokenizer` and instantiating it directly by name. While a subclass can easily hook implementation details of the original module (its superclass) at the method level by overriding that method and delegating to it, the language affords no easy opportunity for the surgical replacement in e.g. `VisualFooParser` of the instantiation (or use of static methods) of `FooTokenizer` from the original `FooParser`. In fact, the only way to do so would be to isolate any interaction that binds by name to a local (instance) method--don't instantiate `FooTokenizer` directly in the middle of some `FooParser` body, but instead call, say, `this._createTokenizer` which in turn does the necessary work. This is likely to be very annoying since it will result in dozens if not hundreds or thousands of stub methods that merely wrap the invocation of some other module constructor or static method...
Ideally, this would be solved at the language level a la Newspeak, but I fear the environmental constraints makes this a non-starter.
| |||