You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several cases have come up where users have wanted to be able to destructure message with the familiar kotlin syntax. Although this is highly requested it doesn’t come for free. It can become massively error prone for users if they re arrange fields ids or introduce new ones.
I still think a safe implementation can be provided by allowing users to define a “deconstructor” option within their message. Similar to the common proto support of the method signature option. The trade off is that this would make the component extensions explicitly defined and managed by the proto author instead of implicitly determined by the plugin.
There’s a already a branch in progress with a working example but the majority of the effort needed for this is in writing good documentation.
The text was updated successfully, but these errors were encountered:
Several cases have come up where users have wanted to be able to destructure message with the familiar kotlin syntax. Although this is highly requested it doesn’t come for free. It can become massively error prone for users if they re arrange fields ids or introduce new ones.
I still think a safe implementation can be provided by allowing users to define a “deconstructor” option within their message. Similar to the common proto support of the method signature option. The trade off is that this would make the component extensions explicitly defined and managed by the proto author instead of implicitly determined by the plugin.
There’s a already a branch in progress with a working example but the majority of the effort needed for this is in writing good documentation.
The text was updated successfully, but these errors were encountered: