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
Note: WithCompletion also shows this type but it has already been fixed by #2045, once a new release is pushed it will be reflected in pkg.go.dev. However, the solution for this issue would also fix that in case it wasn't fixed already.
Unexported types should not be visible from the outside at all.
There are two possible approaches to solve this:
1- Remove the CLI interface and export cli as CLI (Option will be func(*CLI) error).
2- Change Option to func(CLI) error and type-cast to *cli inside every Option.
I personally don't see any reason to have cli unexported and exposed by an interface as all the fields and methods are unexported except for Run. So I think that the first approach is the less intrusive. The second approach requires to take into account the type-cast every time we create a new Option.
The only scenario where the CLI interface would make sense would be if we wanted to have different implementations, which is something that we haven't planned for now AFAIK.
The text was updated successfully, but these errors were encountered:
Official Go documentation is showing an unexported type
*cli
: https://pkg.go.dev/sigs.k8s.io/kubebuilder/v3@v3.0.0-beta.0/pkg/cli#OptionNote:
WithCompletion
also shows this type but it has already been fixed by #2045, once a new release is pushed it will be reflected in pkg.go.dev. However, the solution for this issue would also fix that in case it wasn't fixed already.Unexported types should not be visible from the outside at all.
There are two possible approaches to solve this:
1- Remove the
CLI
interface and exportcli
asCLI
(Option
will befunc(*CLI) error
).2- Change
Option
tofunc(CLI) error
and type-cast to*cli
inside everyOption
.I personally don't see any reason to have
cli
unexported and exposed by an interface as all the fields and methods are unexported except forRun
. So I think that the first approach is the less intrusive. The second approach requires to take into account the type-cast every time we create a newOption
.The only scenario where the
CLI
interface would make sense would be if we wanted to have different implementations, which is something that we haven't planned for now AFAIK.The text was updated successfully, but these errors were encountered: