-
Notifications
You must be signed in to change notification settings - Fork 206
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
static types improvements #6256
Changes from 1 commit
4169857
52aa261
cf27bc4
c46e789
ab55fb8
89ee478
cafb4e9
5349bf5
34c702b
428b274
7e677cd
503219b
2057268
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,2 +1 @@ | ||
// @ts-check | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. backtrack previous commit? |
||
/** @typedef {import('./psm').PSM} PSM */ |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -152,12 +152,13 @@ | |
* Verify that an alleged Invitation is real, and return the Bundle ID it | ||
* will use for contract code. | ||
* | ||
* @param {ERef<Installation>} | ||
* @param {ERef<Installation>} allegedInstallation | ||
* @returns {Promise<BundleID>} | ||
*/ | ||
|
||
/** | ||
* @template {object} [OR=any] | ||
* @template {object} [OA=any] offer args | ||
* @template {object} [OR=any] offer result | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can these be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes of course. Do you think we should adopt that style? So far we've been using all caps to denote a generic type. Usually one letter. I'm more inclined to If we want to change to words, I'd prefer that be done separately in a repo-wide change. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OA and OR seem strictly worse than either alternative. When a single letter is used, I much prefer to also have some part of the commentary indicate what it's mnemonic for, as is the case here, but I think I saw cases where that was dropped. Do some of the formats for specifying typescript not allow room for comments on individual parameters or template values? If that's the case, I'd prefer clearer names. It's often the case that the role of the templated parameters is opaque from just the type declarations. If I have to specify them for offers, invitations, or start functions, it's really helpful to get an indication of what the missing declaration is for. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the reason generics are usually initialisms is to distinguish from types, which are StudlyCaps. I take the point that it's helpful to have the parameter described, and when using the TS syntax there's no documentation string. So I agree when there are multiple type slots and there isn't a documentation string that we should use the more descriptive name, even it it might be confused with a typedef. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done in #6287 |
||
* @callback Offer | ||
* | ||
* To redeem an invitation, the user normally provides a proposal (their | ||
|
@@ -174,10 +175,10 @@ | |
* values are the actual payments to be escrowed. A payment is | ||
* expected for every rule under `give`. | ||
* | ||
* @param {ERef<Invitation<OR>>} invitation | ||
* @param {ERef<Invitation<OA, OR>>} invitation | ||
* @param {Proposal=} proposal | ||
* @param {PaymentPKeywordRecord=} paymentKeywordRecord | ||
* @param {object=} offerArgs | ||
* @param {OA=} offerArgs | ||
* @returns {Promise<UserSeat<OR>>} seat | ||
*/ | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense for both line 247 and 249 to specify defaults?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so. One is JSDoc telling the consumer what the default is and the other the runtime making it so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The runtime making it happen is on line 254. As I read it (I'm admittedly not the expert here) line 247 says that the AssetKind type doesn't require that its parameter be specified, and if it's omitted from the types, it'll assume
'nat'
. Line 249 says that the call to makeEmpty doesn't require a second arg, with the same default. Don't those have the same impact?If a call appears without the second arg, both typescript and javascript should use
'nat'
. If the arg is provided, both should draw the same conclusion. If there's an explicit declaration that conflicts with the code, TS should complain. Won't all the same things happen if line 247 has the default and 249 doesn't?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I misread the discussion as being about line 254 (the runtime default).
You're right, 249 shouldn't have a default. I'll fix in this in #6287