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
Currently, there is a directory named "validation" that houses a folder named "util" and a package and file both named "utils". Nothing in this "utils" package does validation. There are only a couple things and they do some translation from Go types to pointer of custom types, which is entirely the same a currently open PR, which adds a file named "helper.go" to the root of the API directory (for both API versions) and adds the same type of translations.
That made me wonder if these translations should be split into separate packages. I don't think so. If not, then where, under the existing "validation" folder? One could argue that these are utils exclusively there to support the code that does validation. However, as the PR above signals, and in my own usage, that conversion functionality is very useful for interacting with the entire gateway api code base.
The problem I am thinking to solve:
keep like things together
have things be easily discoverable if we can help it
I propose moving the "util" folder out from under "validation" so they are parallel to each other. And rename things so both the package and folder match. I personally prefer util/util (singular).
The content of the "helper.go" file in the above PR should go in this package. The file itself could have a more precise name. Why name it something vague (helper, util) when everything in it is doing something very specific? The package could remain with the name util/utils so it servers as a holding place for future type of utility/helper things, but the file or files could be organized in a way as to reflect their contents. Could be that all of the existing + content of the PR mentioned would go in a file named "translation.go" or "conversion.go", or they could be split into separate files if it would make it helpful to make some further distinction for that content.
Currently, there is a directory named "validation" that houses a folder named "util" and a package and file both named "utils". Nothing in this "utils" package does validation. There are only a couple things and they do some translation from Go types to pointer of custom types, which is entirely the same a currently open PR, which adds a file named "helper.go" to the root of the API directory (for both API versions) and adds the same type of translations.
Current layout:
New PR: Add utils to translate custom types by abhijit-dev82 · Pull Request #1310 · kubernetes-sigs/gateway-api. An exception with this PR is that it also adds translation of the other way around (from custom type pointers to Go types).
That made me wonder if these translations should be split into separate packages. I don't think so. If not, then where, under the existing "validation" folder? One could argue that these are utils exclusively there to support the code that does validation. However, as the PR above signals, and in my own usage, that conversion functionality is very useful for interacting with the entire gateway api code base.
The problem I am thinking to solve:
I propose moving the "util" folder out from under "validation" so they are parallel to each other. And rename things so both the package and folder match. I personally prefer util/util (singular).
The content of the "helper.go" file in the above PR should go in this package. The file itself could have a more precise name. Why name it something vague (helper, util) when everything in it is doing something very specific? The package could remain with the name util/utils so it servers as a holding place for future type of utility/helper things, but the file or files could be organized in a way as to reflect their contents. Could be that all of the existing + content of the PR mentioned would go in a file named "translation.go" or "conversion.go", or they could be split into separate files if it would make it helpful to make some further distinction for that content.
Proposal:
The text was updated successfully, but these errors were encountered: