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
With the recent addition of additional arguments with v2 the functions became very hard to use (or rather, even worse than before).
Without advanced IDE support that shows the parameter names inline (only GoLand for now) it's very hard to identify the arguments, especially when omitting a lot of them. A common pattern in Go is using a struct as a single argument, that then contains the different options. It has several advantages over the current approach:
shorter method signature
optional arguments can simply be omitted
used arguments are easy to identify as you have to put the attribute name in front of them
easy to expand with further attributes without breaking changes
The latter is a lot easier to read and understand quickly. While it would be another breaking change in a short time, it's a worthy improvement in my opinion.
Also, if you would've used this approach before, a lot of the breaking API changes with v2 wouldn't have been breaking changes.
The text was updated successfully, but these errors were encountered:
Thank you for your report. Yes, there is such a problem. There were reasons to move to the form of passing parameter values as a literal list. But this was considered as a temporary solution.
Now we are on the way of reconsidering the API of the Go-client for WAPI and stabilizing it to avoid possibilities of breaking changes in the future as much as possible. And your proposal is one of the main points. Thank you again.
With the recent addition of additional arguments with v2 the functions became very hard to use (or rather, even worse than before).
Without advanced IDE support that shows the parameter names inline (only GoLand for now) it's very hard to identify the arguments, especially when omitting a lot of them. A common pattern in Go is using a struct as a single argument, that then contains the different options. It has several advantages over the current approach:
for example:
could become
The latter is a lot easier to read and understand quickly. While it would be another breaking change in a short time, it's a worthy improvement in my opinion.
Also, if you would've used this approach before, a lot of the breaking API changes with v2 wouldn't have been breaking changes.
The text was updated successfully, but these errors were encountered: