mathjs: [Design question] I don't like `factory`. Why don't we just use modules?
I’m working on this PR and the current dependency system of math.js seems really frustrating to me.
^^ the first lines of a more complicated script look like this with
factory
To be more precise, I don’t understand why don’t we use ES6 modules more, instead of the factory
function which to me seems worse in many ways (the code isn’t DRY at all, worse IntelliSense, problems with circular dependency).
I have a vague understanding that math.js has custom bundling support and some package-wide settings and that’s the reason why factory
was invented, but I think these should be doable with modules too.
So what’s the reason why we use factory
again? 😁️
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 38 (12 by maintainers)
Commits related to this issue
- Try out performance of dependency injection on individual function signatures (see #1975) — committed to josdejong/mathjs by josdejong 2 years ago
On scalar functions:
I am thinking/hoping that the template implementations will be as good or better on both of these counts.
The Pocomath-style of infrastructure has no problem with co-recursion (as long as it bottoms out at some point). For example, the exact circular dependency you mention currently exists in Pocomath as it stands right now: the generic implementation of
divide
is via theinvert
operation (invert and multiply), andComplex
relies on the generic, supplying a definition ofinvert
that in turn usesdivide
(on its components). No special handling/syntax/anything is needed for such references, they are all just resolved at “bundling” time, as I call it (constructing a typed-function from the accumulated implementations for different signatures via the_bundle
method, nothing to do with build-time bundling of JavaScript with webpack etc.) So that aspect will not require separate scalar functions.