$reflect macro at the bottom of the files
Thanks! From your comments at glen/math5#1 (comment) I understand that the builder pattern is indeed necessary. So no need to work this idea out…
$reflect macro at the bottom of the files
math5 vs dispatch_refactor approach
Thoughts about a build step to generate types: in the current mathjs there is also a build step in place which generates files. In ./src/entry/ there will appear files named *.generated.js.…
math5 vs dispatch_refactor approach
to me by far the most powerful argument is that math5 actually found typing violations in the implementation code that dispatcher_refactor did not.
Agree, you're right, that is a strong…
$reflect macro at the bottom of the files
I feel we need a solution that will automatically allow
<T>add(Complex<T>, T)via the automatic conversion
Yes, totally agree!
Options (2/2b) still look feasible, although yes, they…
Having to specify whether to $reflect generic or not is indeed not ideal but acceptable at least for now. I agree on parking $$typeMetadata! for now, it's not a magic solution.
My idea is…
Hmm, all these new TS issues suck, we definitely don't want that.
The $$typeMetadata! sounds promising!
In my head, Typocomath is an extension on top of Pocomath. I think the step to…
Ok I'll look into the .reflectedType issue next week. And indeed it may not be an issue in practice since it's an under the hood thing, I'll keep that in mind.
The lazy approach of the…
In 6bfd06cafb I've added code to extract the generic parameter from the reflectedType.
That's good news!
I've checked out the latest version of main, and can successfully run pnpm go. There was one typo export type FunctionDef {, I've changed that to `export type…
If we implement the Dispatcher as a class, we should not attach functions to itself, then we mix things up.
However, the end user is probably not interested in a verbose `const math = new…