Loss of flexibility when using generated flag accessors

[sahidvelji]

When using generated flag accessors, at least in Go, the user no longer has access to the client. This has several implications:

1. There is no way for the user to evaluate a flag using a client bound to a provider other than the default provider. Of course this can still be done by creating a new client and performing the evaluations without using the generated code, but that defeats the purpose of generating the code.
2. A user cannot perform the usual actions on the client, such as setting an evaluation context or calling client.Track.

https://github.com/open-feature/cli/blob/main/internal/generators/golang/golang.tmpl

Suggestions:

1. Export the names of the generated flags as constants so that users can access the flag names if they need to.
2. Maybe adjust the schema by adding an optional domain field to each flag that specifies which domain to use to evaluate that flag.
3. An alternative to point 2: maybe even go as far as to have users (in the flag manifest file) specify an optional array of domains for which they want to generate flags/clients. Then generate flag accessors and a client for every domain that was listed in the flag manifest file.
4. Export the generated client(s) so that users can access them if needed in order to, for example, add hooks at the client level.

[beeme1mr]

Yes, this is a good point. Perhaps we should take a step back and reevaluate the structure of the generated code. Let me think about it a bit more. @sahidvelji would you mind pseudocoding your ideal generated client for Go?

[sahidvelji]

Maybe the functions could take a client parameter as input. 🤔

I'd need to think about this a bit more as well. Maybe we just have 2-3 different templates for each language and let the user decide via the config file or command line flag as to which one they want, with the option to use an entirely custom template if needed. This is kind of related to #165.

Maybe adjust the schema by adding an optional domain field to each flag that specifies which domain to use to evaluate that flag.
An alternative to point 2: maybe even go as far as to have users (in the flag manifest file) specify an optional array of domains for which they want to generate flags/clients. Then generate flag accessors and a client for every domain that was listed in the flag manifest file.

This might actually not make sense since the flag manifest file is meant to be fetched and not handwritten. So using the config file for this purpose might make more sense. But in general I think if we solve for #165, then the problems described in this issue go away. But, we should have 2-3 versions of our templates for each language, where it makes sense.

[kriscoleman]

I wonder if we could expose the underlying client in our generated client for each flag.

something like:
flags.EnableApi().Client.Track()