-
Notifications
You must be signed in to change notification settings - Fork 310
KG-508 Update Tool API to fix name and descriptor discrepancy and make it more robust #1226
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
Conversation
c1c2967 to
17f3530
Compare
Qodana for JVM1168 new problems were found
@@ Code coverage @@
+ 72% total lines covered
16835 lines analyzed, 12215 lines covered
# Calculated according to the filters of your coverage tool☁️ View the detailed Qodana report Contact Qodana teamContact us at [email protected]
|
kpavlov
left a comment
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.
Hey @EugeneTheDev, could you please add a PR description and update the identity tool’s name and description before we merge?
| name = SubgraphWithTaskUtils.FINALIZE_SUBGRAPH_TOOL_NAME, | ||
| description = SubgraphWithTaskUtils.FINALIZE_SUBGRAPH_TOOL_DESCRIPTION |
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.
Is it a copy from finalize tool?
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 was like this before. This identityTool is internal and is used actually only as a finalize tool to provide the final result, hence the finalize tool name. Sounds like we can leave it as it is. Or do you want me to make name and description configurable (although there's no use for it currently). wdyt?
38399db to
ec28f10
Compare
|
Updated description |
Qodana for JVM1206 new problems were found
@@ Code coverage @@
+ 72% total lines covered
17235 lines analyzed, 12530 lines covered
# Calculated according to the filters of your coverage tool☁️ View the detailed Qodana report Contact Qodana teamContact us at [email protected]
|
…e it more robust (#1226) **This PR introduces breaking changes in Tool API** Currently `argsSerializer`, `resultSerializer`, `name`, `description` and `descriptor` are meant to be overriden to provide your own values. Since we can also generate `descriptor` automatically now, it introduces a discrepancy between property values and the actual state of things. It's described in [KG-508](https://youtrack.jetbrains.com/issue/KG-508). So current version makes for unstable and somewhat confusing API. In this PR, I've moved these configurable tool properties to the constructors instead. This avoids confusion, since now the ways in which you can configure the tool are visible more explicitly - either provide your own `descriptor`, or opt for an automatic generation and only provide `name` and `description`. Updated API also looks a bit more concise and fluent, IMHO, since you have to write less `override` now. Compare these: ```kt // Before object DummyTool : SimpleTool<Unit>() { override val argsSerializer = Unit.serializer() override val name: String = "dummy" override val description: String = "Dummy tool for testing" override suspend fun doExecute(args: Unit): String = "Dummy result" } // After object DummyTool : SimpleTool<Unit>( argsSerializer = Unit.serializer(), name = "dummy", description = "Dummy tool for testing" ) { override suspend fun execute(args: Unit): String = "Dummy result" } ``` Also, another breaking change, as you have already seen from the example above, is `doExecute` removal. It is not needed anymore, since tools support primitive types now, so you can just use a regular `execute`
This PR introduces breaking changes in Tool API
Currently
argsSerializer,resultSerializer,name,descriptionanddescriptorare meant to be overriden to provide your own values. Since we can also generatedescriptorautomatically now, it introduces a discrepancy between property values and the actual state of things. It's described in KG-508. So current version makes for unstable and somewhat confusing API.In this PR, I've moved these configurable tool properties to the constructors instead. This avoids confusion, since now the ways in which you can configure the tool are visible more explicitly - either provide your own
descriptor, or opt for an automatic generation and only providenameanddescription. Updated API also looks a bit more concise and fluent, IMHO, since you have to write lessoverridenow. Compare these:Also, another breaking change, as you have already seen from the example above, is
doExecuteremoval. It is not needed anymore, since tools support primitive types now, so you can just use a regularexecute