On Sun, Jun 7, 2020 at 12:04 PM Diego Augusto Molina <diegoaugustomol...@gmail.com> wrote: > > Very often I use the stringer command to generate lists of enumerated values, > which is great btw. > But one thing that I see myself also writing after this is a Parse method or > function to validate strings that are received. > The use case is that I have a list of possible values for a controlled field > in a RESTful API. I receive and deliver string values from the API by I have > a tight control inside the API itself. > I declare a new type (generally an uint8 alias) and then declare a bunch of > auto incremental constants, starting with the zero value that I always set to > "Invalid" which is used as a control value. > The stringer command makes the dull work but immediately after I write a > Parse function or method. The following is a full example: > //go:generate stringer -linecomment -output=enum_string.go -type=MyEnum > package enum > > type MyEnum uint8 > > const ( > // Reserved for internal use > MyEnumInvalid MyEnum = iota // Invalid > > MyEnumValue1 // Value #1 > MyEnumValue2 // Value #2 > MyEnumValue3 // Value #3 > MyEnumValue4 // Value #4 > MyEnumValue5 // Value #5 > ) > > func (e *MyEnum) Parse(value string) MyEnum { > for lenIdx, lenVal, i := len(_MyEnum_index), uint8(len(value)), 1; i < > lenIdx; i++ { > if _MyEnum_index[i]-_MyEnum_index[i-1] == lenVal && // Maybe too > small optimization to be perceptible/useful(?) > _MyEnum_name[_MyEnum_index[i-1]:_MyEnum_index[i]] == value { > *e = MyEnum(i - 1) > return *e > } > } > return MyEnum(0) > } > > So this couples a lot to my workflow, of course. This way I can do something > like: > receivedVal = new(MyEnum).Parse(receivedStr) > Or: > var val *MyEnum > for _, strVal := range strValues { > if val.Parse(strVal) == MyEnumInvalid { > return fmt.Errorf("Invalid value for enum: %v", strVal) > } > } > > So I started to write this function within the stringer command, which I > modified to do so. So I don't know if this is for some use to the community. > I know that in order for it to be useful to everyone it should be more > general. So I'm looking at alternatives and, of course, if it's worth working > on that. I it would be of some use there are two alternatives where this > could live: > > As an option to the stringer command > As a separate command (because it would exceed the stringer interface and > would be misleading, since "Parse" is not part of the "Stringer" interface) > > And I'm only using here the stringer command to create series of consecutive > numbers, so I would need to write extra code to fulfill the sparsiness of > values (cases where stringer creates up to 10 different slices and after that > just creates a map). It wouldn't be much work, actually, just read the code > in the command. > And instead of writing a new method for the type (breaking the idea of the > "stringer" interface), I thought it could just be a "ParseT" function. > > Thoughts? Comments? Should I keep it for myself (hahaha)?
There are many different possible enhancements that can be made to stringer. We've decided to keep the tool simple rather than add additional knobs. Thanks. I encourage you to make your tool available for anybody who wants to use it. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV8PwDGcf4Np5vr44TsFsSOv8tuJ3NpKOK1km%2B%2BFcPSJQ%40mail.gmail.com.