Adds Calculator.make(fn) call #2660
Conversation
🦋 Changeset detectedLatest commit: 0963778 The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
Apply Sweep Rules to your PR?
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2660 +/- ##
==========================================
- Coverage 71.77% 71.65% -0.13%
==========================================
Files 115 115
Lines 6207 6219 +12
Branches 1220 1222 +2
==========================================
+ Hits 4455 4456 +1
- Misses 1744 1755 +11
Partials 8 8 ☔ View full report in Codecov by Sentry. |
| name: `Input ${i + 1}`, | ||
| type: sig.getName() === "Bool" ? "checkbox" : "text", | ||
| })), | ||
| sampleCount: 10000, |
There was a problem hiding this comment.
Huh, why? Shouldn't this be inherited from environment, like in user-defined lambdas?
There was a problem hiding this comment.
I wanted this to be a bit higher than normal, because these are probably fairly small (just one function).
That said, as I think about it, maybe it could be a very expensive function. Can change.
| @@ -193,6 +207,20 @@ export class BuiltinLambda extends BaseLambda { | |||
| } | |||
| throw new REOther(showNameMatchDefinitions()); | |||
| } | |||
|
|
|||
| toCalculator(): Calculator { | |||
| const longestSignature = maxBy(this.signatures(), (s) => s.length) || []; | |||
There was a problem hiding this comment.
This is a reasonable heuristic, but it could cause some frustration if the longest signature is not the most natural one.
Brainstorming other, more general approaches:
Calculator.make(fn) -> Calculator[](return all possible versions)Calculator.make(fn.definitions[i]) -> Calculator, wherefn.definitions[i]returns a specialized function with a single signature (but this is awkward because it means thatfn.definitions[3][0][0][0][0][0]should be allowed)Calculator.make(fn, 3) -> Calculator(same asCalculator.make(fn)[3]in (1) above)
There was a problem hiding this comment.
Thanks for the ideas, but I don't think I'm a fan of those.
- This could be messy, especially if there are many definitions (you'll get 3-10 on some items). I'd expect it to surprise users.
- Agreed it's awkward. Slow to type out.
- Also seems weird, especially as the order of definitions might be a bit chaotic.
One nice thing is that this issue should only come into play for builtin functions - users functions only have one definition.
My guess is that we should leave for now. However, here are some options for later:
-
Maybe, if there are multiple definitions, then if you try
Calculator.make()without any definitions, it shows you an error, but gives you a list of definitions as strings. You then can plug them in as,Calculator.make(defString). -
We output a Dict, where keys have to do with the definitions somehow.
-
We output a small dropdown menu of definitions, after which the correct form will appear.
A quick way to turn functions into calculators, for testing. Will be more useful with Tags, soon.