-
Notifications
You must be signed in to change notification settings - Fork 205
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
add basic checks extension macro #3315
Conversation
}); | ||
} | ||
|
||
class Person { |
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.
Can we make an example where the class we generate for is imported?
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.
It doesn't make any difference in this case - and the boilerplate required right now for running these is already a lot, I don't really want to add more files.
For the real macro, once you can run it in a more sane way, you could absolutely do that.
'@', | ||
checksExtension, | ||
'()', | ||
'extension $name on ', |
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.
This is interesting - it looks like the macro runs in two steps?
Does that mean that folks who want more customization can do something like
@ChecksExtension()
extension CustomName on Subject<SomeType> {}
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.
Yeah, it wouldn't have to work this way but that is imo the best way to write it. It would have to run in two phases regardless.
The macro could be smart enough to skip adding extensions that already exist though, so you could write custom ones and have it fill in the rest.
I am not sure all other macro use cases would want the 2nd macro (@ChecksExtension()
here) to actually be visible so it is a little weird. It could actually exist in a src
library, so that might be the solution "hiding" it. But it has to be public.
This macro generates extensions for a list of types, for use with
package:checks
. It isn't yet runnable as I need to do a bit of upstream work, but should be a good start.I also updated the spec for extensions, allowing introspection on the
on
type as well as all generic type parameters. @munificent I added you to review that part. I also reworded that section just a bit and added a bit more general clarification.