Generate Stringers

[mogsie]

When working with feature flags, it's sometimes necessary to access the original feature flag key buried inside the generated code.

Here are some examples:

1. In our test cases, we use environment variables to control flags, and we have to duplicate the feature flag name to mimic the uppercase'd underscored mapping ("FEATURE_MY_FEATURE").
2. For prometheus, you have to set up the valid metrics at initialization time, well before evaluating any metrics
3. You might also provide command-line flags to set features. For those you need information about (at least) the name of the flag.

It would be great if the generated code had the ability to access this original string, without having to e.g. evaluate the flag.

In go, it could be something like this:

// stringer transforms a string to a Stringer
type stringer string

// String implements the fmt.Stringer interface
func (s stringer) String() string {
	return string(s)
}

var MyCoolFeature = struct {
	fmt.Stringer
	Value BooleanProvider
	ValueWithDetails BooleanProviderDetails
}{
	Stringer: stringer("my-cool-feature"),
	Value: func(ctx context.Context, evalCtx openfeature.EvaluationContext) (bool, error) {
		return client.BooleanValue(ctx, "my-cool-feature", false, evalCtx)
	},
	ValueWithDetails: func(ctx context.Context, evalCtx openfeature.EvaluationContext) (openfeature.BooleanEvaluationDetails, error) {
		return client.BooleanValueDetails(ctx, "my-cool-feature", false, evalCtx)
	},
}

The caller can then know the original key of a provider by stringing it.

MyCoolFeature.String()

And from there, we could do things like craft environment variables, or command line flags.

[beeme1mr]

Hey @mogsie, thanks for bringing this up. I think it makes sense to expose the flag key back to the user. I hadn't considered the use case you mentioned but I understand the challenge you're trying to solve.

This would work with our Go implementation but not in other languages without some changes to the generated client. I still think it's worth considering prior to changing the stability level past alpha.

Another potential option would be to expose a map of flag keys in the generated output. I think I prefer your proposal, but it's another approach worth considering.

FYI @anghelflorinm @kriscoleman

[mogsie]

Yes, in fact adding a map of flag keys would also solve my other problem (for which I didn't open an issue), essentially enumerating the available feature flags.

I opened this issue mainly to hear if you wanted to go in this direction, and of course to offer to implement it 👍

A go map would have to be map[string]any unless we also generated generic code? And possibly easier to implement in other languages?

A list of strings would also be possible, but then you wouldn't know where to look for it, so I think a map / dictionary of some type would be best.

[mogsie]

Hmm. Generics won't work because we can't have heterogeneous maps, and the underlying types (from go sdk openfeature, like BooleanEvaluationDetails) aren't generic.

Since there are four or five types, maybe we could just generate four more variables:

var BooleanProviders = map[string]BooleanProviderDetails{
	"enableFeatureA": EnableFeatureA.ValueDetails,
}

So then you could range over these and deal with the BooleanProviders at least, and evaluate them all.

[beeme1mr]

I'll think about it a bit more and see if anyone else has an idea. I'm definitely open to the idea but I'd really like to think through the DX before we commit one way or another.

If you're looking for more rapid feedback, consider joining the #openfeature-cli Slack channel on the CNCF workspace and/or the CLI-focused community call next Tuesday.

[kriscoleman]

@mogsie would love your eyes on #167