-
Notifications
You must be signed in to change notification settings - Fork 14
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
Experiment with dynamic call origin information #88
base: master
Are you sure you want to change the base?
Conversation
looks good. what do you think of a different name for |
Or keep it close to the lib... @PowerAssert? |
c9e8f1f
to
7372943
Compare
I've been thinking about renaming this repository for a while since it is starting to handle so many use-cases outside of just asserts. Especially with this new annotation driven stuff, I see it as a chance to do some rebranding. So I'm hesitant to go with I do like But nothing is set in stone yet; naming ideas are very welcome for everything related to this PR! |
what about merging this to master and releasing it as an experimental feature for people to play with it? |
I plan to do that, but right now I've only created the constructs people will use and not implemented anything on the compiler plugin side of things yet. Still lots of work to do before this is useable. |
Experimenting with what an annotation driven form of kotlin-power-assert would look like, and what form the data structure would take for getting call source information.
Goal is to handle as much boiler-plate as possible and not exposing the mechanics of how call-site information is passed. This also hopefully means that libraries which have
@Introspected
functions would only need to include the support library as acompileOnly
dependency, since any calling code would also need to include the compiler plugin anyways.