Conversation
644b4f6 to
aec653a
Compare
| * methodGuards: M, | ||
| * options?: {sloppy?: false}): InterfaceGuard<M>; | ||
| * options?: { | ||
| * sloppy?: false, |
There was a problem hiding this comment.
@turadg , since I'm unsure why you split these cases on sloppy true vs false, I may be doing the wrong thing in not splitting on unprotected true vs false. Truly there are three cases: (false,false), (true,false), and (false,true). If I had not already introduced a boolean option, I would have made it a three-way. Oh well.
There was a problem hiding this comment.
The reason for the overloading here is that sloppy:true implies InterfaceGuard<any> (everything matches) and sloppy:false parameterizes InterfaceGuard with the type of methodGuards.
I take it that "unprotected" should be InterfaceGuard<any> so this type needs more work. But let's settle on the API first.
I would have made it a three-way
It's not too late! We could make it sloppiness: 'none' | 'sloppy' | 'unprotected' and still retain backwards compatibility with true ('sloppy') and false ('none')
There was a problem hiding this comment.
It's not too late! We could make it
sloppiness: 'none' | 'sloppy' | 'unprotected'and still retain backwards compatibility withtrue('sloppy') andfalse('none')
Bikeshedding on how to spell this option: how about defaultGuards: 'never' | 'passable' | 'unprotected' with the same semantics for sloppy: true (defaultGuards: 'passable') and sloppy: false (defaultGuards: 'never').
I don't intend for that to be the final word; just presenting an idea.
|
Successor to #1724 |
| * methodGuards: M, | ||
| * options?: {sloppy?: false}): InterfaceGuard<M>; | ||
| * options?: { | ||
| * sloppy?: false, |
There was a problem hiding this comment.
The reason for the overloading here is that sloppy:true implies InterfaceGuard<any> (everything matches) and sloppy:false parameterizes InterfaceGuard with the type of methodGuards.
I take it that "unprotected" should be InterfaceGuard<any> so this type needs more work. But let's settle on the API first.
I would have made it a three-way
It's not too late! We could make it sloppiness: 'none' | 'sloppy' | 'unprotected' and still retain backwards compatibility with true ('sloppy') and false ('none')
505f81f to
c2cd034
Compare
aec653a to
e6831ea
Compare
|
Converted to Draft in anticipation of successor from @michaelfig . Once that's pushed, I'll close this one. |
|
In experimenting with this API, I've come to feel that So, I've created #1772. Please take a look. |
@michaelfig , does this do what you need at this stage, i.e., without yet addressing the zone-POLA issue?
Not at all yet tested.