-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Checker" parameters would be more ergonomic as "Rejectors" #2285
Comments
I like this a lot! Deprecation is somewhat of an issue. Fortunately, most packages only use a |
Hmm, I was thinking the "check" names would remain, but that does make sense. The "is" names would be perfect if they weren't theirselves exposed, but I'd rather not reveal this new pattern (at least not right now). So I guess we're looking at synonyms or near-synonyms of "check" ("verify", "ensure", "test", "matches", etc.). What about "matches", in loose correspondence with patterns? export const isSafePromise = pr => matchesSafePromise(pr);
export const assertSafePromise = pr => matchesSafePromise(pr, Fail); I think that would work directly everywhere except in patternMatchers.js, where we'd probably redefine both |
I like the direction. I'm ok with the choice of |
After more reflection, I really don't like |
https://www.merriam-webster.com/thesaurus/verify suggests "confirm", "validate", "certify", "affirm", etc. Of the entire list, I think I like "verify" and "confirm" best. export const isSafePromise = pr => verifySafePromise(pr);
export const assertSafePromise = pr => verifySafePromise(pr, Fail); export const isSafePromise = pr => confirmSafePromise(pr);
export const assertSafePromise = pr => confirmSafePromise(pr, Fail); |
Both sound good to me. I like |
What is the Problem Being Solved?
#2284 demonstrated that there is a relatively small but still significant performance cost to creating
reject = !!check && ((T, ...subs) => check(false, X(T, ...subs)))
functions that will only be used in failure paths, and so moved that definition into a newCX
function and updated many sites to use that:However, this has drawbacks of its own with respect to comprehensibility and readability, especially when prettier introduces line breaks like
Description of the Design
I think we'd be better off replacing
(cond: boolean, details?: Details | undefined) => boolean
"Checker" parameters with optional(template: TemplateStringsArray | string[], ...args: any[]) => false
"Rejector" parameters, recovering the old local pattern but without local function creation.And per #2285 (comment) , we'll also want to rename internal functions for indicating the progress of this transition.
And at the highest possible level, we'd replace use of
x => x
checkers withundefined
rejectors andassertChecker
withassert.Fail
.Security Considerations
None that I can see.
Scaling Considerations
Negligible, but the new pattern might be slightly faster.
Test Plan
n/a, this is behavior-preserving refactoring.
Compatibility Considerations
assertChecker
is exported by the pass-style package, and used by at least the patterns package, which also makes use of checkers so should be updated similarly. But I think all such use is internal for supporting {is,assert}$Type package exports (e.g.,isKey
andassertKey
).Upgrade Considerations
If any exports do expose a Checker parameter, we'll need to consider a deprecation strategy.
The text was updated successfully, but these errors were encountered: