Keeps track of which operations depend on the configuration and invalidates them for lazy reconfiguration when the config changes.
|6 months ago|
|complex||6 months ago|
|generic||6 months ago|
|number||6 months ago|
|test||6 months ago|
|.gitignore||6 months ago|
|LICENSE||6 months ago|
|README.md||6 months ago|
|package-lock.json||6 months ago|
|package.json||6 months ago|
|picomath.js||6 months ago|
|picomathInstance.js||6 months ago|
|poortf.js||6 months ago|
An instance of the system will be an object whose property names are the operator names and whose property values are constant mutable function objects that can have new behaviors added to them.
Calling the system on a property name and 0 or more implementations creates that operator if it doesn't exist and adds the implementations to it, and returns the function object for that name. Thus, it is easy for modules to obtain handles to operations they depend on, and to create/extend an operation (typically just one per file at the moment).
Multiple different instances can coexist and have different collections of operations. Moreover, only the source files for the operations actually desired are ever visited in the import tree, so minimizing a bundle for a specific subset of operations should be quite straightforward.
Hopefully the test cases, especially
test/custom.js, will show this off in action.
Note that 'subtract' is implemented as a 'generic' operation, that depends only on the 'add' and 'negate' operations (and so doesn't care what types it is operating on).
This core could be extended with many more operations, and more types could be defined, and additional sub-bundles like
number/all.js or clever conditonal loaders like
complex/extendByComplex could be defined.
Hopefully this shows promise.