feat(patterns): helper for interface guard inheritance#2953
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR introduces a helper function getNamedMethodGuards to support interface guard inheritance patterns. The function enables developers to extend one interface guard from another using JavaScript's spread operator.
- Adds
getNamedMethodGuardsfunction that extracts string-named method guards from an interface guard - Updates comment formatting for consistency with JSDoc standards
- Fixes default guard assignment logic in exo-tools.js
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| packages/patterns/src/patterns/getGuardPayloads.js | Adds the new getNamedMethodGuards helper function and improves comment formatting |
| packages/exo/src/exo-tools.js | Fixes default guard assignment to use undefined instead of the uninitialized variable |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
There was a problem hiding this comment.
Pull Request Overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
a4dba17 to
ee45ea2
Compare
There was a problem hiding this comment.
Pull Request Overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
24cc9d2 to
01b3db6
Compare
|
Ready for review |
There was a problem hiding this comment.
Pull Request Overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
01b3db6 to
679e7a8
Compare
679e7a8 to
8937953
Compare
8937953 to
02afa86
Compare
Closes: #XXXX
Refs: https://hackmd.io/@rekmarks/H1X6VtP5eg#
Description
https://hackmd.io/@rekmarks/H1X6VtP5eg# @rekmarks explains the need to express that one interface guard effectively extends another. In a slack thread, @michaelfig explains how all we need is a helper that can extract the method guards from an super/base interface guard which can then be used with
...when defining a sub/derived interface guard. Revising the name to fit this PR, @michaelfig 's pattern isBy putting the
...first, the sub/derived interface guard can override "inherited" interface guards as well as adding new ones.Note that this ignores symbol-named method guards. This feature is deprecated anyway, and will hopefully disappear soon. (TODO links to PRs that will make symbol-named methods and method guards disappear.)
Security Considerations
By making it easier to express interface guards, programmers are more likely to use non-vacuous interface guards, i.e., with method guards. Without explicit method guards or patterns, our experience is that ad-hoc input validation is hard. Interface guards with method guards with patterns expresses the type-like portion of interface validation in a declarative, readable, reviewable, and sound manner. The remaining input validation burden on the manually written "raw" exo methods then is more like it would be in a soundly-statically-typed ocap language. In our before/after experience, this is typically much smaller and more reliably reviewable.
Thus, this change is good for security.
Scaling Considerations
none
Documentation Considerations
@michaelfig 's inheritance pattern is nice and should be explained somewhere. Where?
Testing Considerations
Tested in @endo/exo by exo-wobbly-point.test.js since that's already about class inheritance, which naturally goes with interface inheritance.
Compatibility Considerations
It ignores symbol-named methods. This is unlikely to cause any problems now, and will help prevent new problems when we withdraw that "feature".
By internally using
getInterfaceGuardPayload, we remain tolerant of the old deprecatedklass-based interface-guard representation. Unfortunately, this compat is still needed by agoric-sdk.Upgrade Considerations
none. Unless I'm missing something?