Ah, I understand what you mean now, I wasn't aware of the TD.resolve('config', [BigNumber]) solution, your idea for type based configuration. I think my latest example proposal basically has…
instanceof and avoid inheritance, specifically in TypePattern.
Yes indeed, instanceof doesn't reliably work between iframes and the main window.
(A) 👍 (B) I have a strong feeling that it would be better to keep the data type itself and the type information about the data type separate from each other, but I don't have a full picture of…
So far it's just a wild idea, I would be curious to see if that could work out nicely.
Should that be on a per-value basis?
I think that would complicate things quite a bit, I would prefer…
instanceof and avoid inheritance, specifically in TypePattern.
I like the famous "prefer composition over inheritance"😄. I'm totally fine with using classes by themselves, but in my experience it helps to keep complexity managable by using inheritance as…
pnpm test
@glen it would help me a lot if you can rename the Type.js function soon. Right now I can't work with nanomath on my machine.
TypePattern into an interface?
Maybe we can think through a way to configure the precision based on the max precision offered by the numeric type at hand, so the same config works for both number and BigNumber, and automatically…
(A) I have no strong opinion in this regard. I prefer to have 1 way to do things though. (B) Is it needed to create type objects on top of the primitive types (which are already built in)? If so,…
It makes sense indeed, it's indeed a good thing to have a high precision version of the constants (when available), and go from there! I think in some cases we can also lazily calculate a…
I think it will be nice if values (constants) like tau or pi can be imported as is, without a wrapper function. They don't have to be matched to anything except their name, and they aren't…
@glen wrote in StudioInfinity/nanomath#12 (comment):
Would you prefer to require the
match(Passthru, ...)for uniformity, or are you OK with…
Ah, ok, yeah that sounds good to me. It is quite a common case indeed so nice to have.
Yeah, good point, I think match is better than on. De dispatcher is indeed "just" doing pattern matching :). Ok let's go for match then.
Well, I think it is unambiguous and convenient…
😂 I hear some frustration about formatters. I myself love them, it helps a lot ensuring a consistent and unified style in a code base, and it saves me time when styling and indentation is…
Ah I see. The alternating pairs are indeed concise, but I think it would be better to have a bit more explicit API. When using automatic formatters for example, I expect all arguments to be put on…