-
Notifications
You must be signed in to change notification settings - Fork 105
initial port of dartantic_interface types #619
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
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.
Code Review
This pull request introduces a new package genai_primitives by porting several types from dartantic_interface. The changes include new data models for chat messages, message parts (text, data, links, tools), and tool definitions, along with a comprehensive example and unit tests. The overall structure is good, but I've found several critical issues with equality checks and hashCode implementations that could lead to incorrect behavior, particularly when using these objects in hash-based collections. Additionally, there are some concerns with JSON serialization and a dependency on a private API. My review comments provide specific suggestions to address these points.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
| } | ||
|
|
||
| /// The role of a message author. | ||
| enum ChatMessageRole { |
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 you add more details to doc strings for enum and its items?
I can represent a confused user here:
-
doc for enum is saying that each item is a role of a message author, while doc for each item is describing type of message, not author
-
can you elaborate what is 'system'?
-
documentation is saying 'from', but not 'to'. Is it correct that system always send messages to model? If yes, should we specify it here? And the same about model: is it correct that model's messages are intended to be handled by system and then system will show to the user whatever is intended for user?
-
or my assumptions above are completely wrong and the enum relates to difference between 'user prompt' and 'system prompt' somehow?
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.
Maybe in this library instead of ChatMessage having field ChatMessageRole role, it make sense for it to have the field 'String type', so that every dependent can define their set of message types.
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.
Another option:
class ChatMessage<T>{
...
final T type;
...
}Then users will be able to pass their enums for the message type. Maybe some of them will have more than one model and more than one system.
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.
Or, we can remove type completely, so that users just derive from ChatMessage and add whatever fields they want to add. Or users can compose ChatMessage into another object, that contains envelope information.
This seems to be cleanest option for me.
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'll elaborate on what the enums mean, but across all of the LLM APIs (and I've built against most of them by now, certainly all of the major ones), it always boils down to role (user or system or model|assistant) and parts. Anything more than that is over engineering, imo.
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 still think having roles itemized makes this library too opinionated.
I would remove role from the message completely, allowing clients to define the roles in their systems.
If you disagree let's merge this as is and have this discussion outside of this PR.
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.
let's talk after the merge.
| final ToolPartKind kind; | ||
|
|
||
| /// The unique identifier for this tool interaction. | ||
| final String id; |
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.
How about renaming it to interactionId, to avoid confusion and make it clear how to name this id, when it is copied outside of this class?
Is it correct that id of tool call is expected to be equal to id of tool call result? If yes, should it be documented here?
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.
yes. that's correct. I'll update the name and the docs.
|
Thank you! It looks good. Left some naming and documentation related comments. |
|
Yes you're correct about the tool result id matching the tool can id. I like the idea of updating the name and the docs to reflect that, although I don't know what that name should be. I'll provide an update ASAP. |
| final Map<String, dynamic>? arguments; | ||
|
|
||
| /// The result of a tool execution (null for calls). | ||
| final dynamic result; |
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.
Should we use Object? instead of dynamic everywhere?
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 second that. Dynamic turns off type checking.
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.
what kind of type checking do we get with Object? the standard JSON in/out in Dart is Map<String, dynamic> -- shouldn't we stick with that? I'm open to changing to Object? if I can understand the reason to vary from the Dart SOP.
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.
There are debates in Dash team if Dart should change the standard.
It is verified that Map<String, Object?> does not break standard json serialization.
With Object you get some minimal static analysis, with dynamic you can invoke whatever field you want.
There are lints that restrict dynamic and we use them.
I suggest |
|
@csells, I raised many questions about minor details. There are options how to proceed:
If you want to actively participate in discussion, let's go with (2). |
Or 'requestId'? |
…oolName` for clarity, and enhance `ChatMessageRole` documentation."
…ble fields and new client properties. Also downstream updates required a new version of dartantic.
…into initial_primitives
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…oolName` for clarity, and enhance `ChatMessageRole` documentation."
…ble fields and new client properties. Also downstream updates required a new version of dartantic.
|
Landed! Thanks to @andrewkolos for the fast fix! Minor suggestion about this PR: how about using |
…into initial_primitives
…age parts and examples. interactionId=>callId.
|
ok @polina-c . I rebased on main, got everything building again and replaced "interactionId" with "callId" as well as most of the other suggestions I well. also, the latest dartantic_ai works with the latest mistral if that's of interest. |
|
Amazing! Thank you 🙏 |
Description
fixes #626
Adds the following types ported from dartantic_interface and migrated to json_schema_builder:
Pre-launch Checklist
///).