Hi, Given your requirements, there's not much left from what make enums superior: having a more or less fixed set of values with arbitrarily complex meanings that can be expressed using only a (small) number. The keyword here is "fix".
Maybe enums aren't just not what you want. If they are changing that often, a plain string approach like Wilm suggested makes probably more sense, I think. JensG ________________________________ Von: Jonathan Kanarek Gesendet: 20.04.2015 08:43 An: [email protected] Betreff: RE: String enums Thank you Wilm for the detailed answer. You are mostly right and I don't think it's the right place to explain myself or my design. I was trying to enjoy the strength of thrift where it comes to fast and simple clients generation because my REST enums are changing in every installation, but obviously I'll need to find a different solution. Thank you, T. -----Original Message----- From: Wilm Schumacher [mailto:[email protected]] Sent: Monday, April 20, 2015 1:02 AM To: [email protected] Subject: Re: String enums Hi, I hope my answer isn't going to be percepted as rude, but your request is kind of strange. "string enums" in the way you described below does not make any sense. You have two concepts: 1.) enums: (internaly of course some integer) the reason why enums are used is to distiguish between something (states or whatever) which only can take a specific non changable set of values. 1,2,3 ... and done, or with names "aaa", "bbb", "ccc" (as enum names, not strings) ... and done. Not more, not less. 2.) strings: well, more or less arbitrary arrays of characters. Without further restriction(!) there is no limit in the set of possible strings. Thus, enums and strings are in that respect kind of opposite concepts. In the respect of representing values of a somehow defined set. And: this is not a thrift question, but a general question on how to represent ... the state, or plugin etc.. In the desription below you wrote something about a "plugin system" where the clients can trigger the function. And of course only if the plugin is available the function can by pulled. >From a thrift perspective (or general coding perspective) the question arises: is the set of values somehow bound to a very specific not/almost not changing set of values which is known beforehand? You answer seems to be "no", thus enums are not working for you. Is there a good representation of your "possible values" by integer? Seems not to be. Thus string seems to be a good idea. As you wrote, a older client could speak with a new servers, thus unkown functions are avaiable and new clients could speak with old servers where there are funtions triggered with no "backend". I would go with something like void triggerFunction( 1:string pluginName , .... ) throws (1:PluginNotKnown, ...) and list<string> availablePlugins( ); // for checking or so. Hope it helps Wilm Am 19.04.2015 um 18:27 schrieb Jonathan Kanarek: > Assuming this enum(AAA = 'aaa', CCC = 'ccc'). > Today the client send the server the string value=aaa and the server > validates it against the optional values. > I can create a server side map that will create a new enum(AAA = 1, CCC = 2) > and when I get value=1 I'll know the client actually means aaa. > > However, our server grows rapidly and new enum values may be added in the > future, e.g. BBB. > How can I make sure that all generated client will match all compatible > versions of the servers on different environments if the map is generated > dynamically based on the existing values. > Note that the order of the values is also not always the same because on > different environments I may install different plugins that may cause > different values sets in the enums. > > Of course that mapping the enums on the client side will only increase the > issue. > > So I was wondering if there is a way to implement string enums using > constants that instantiated with string value for example. > T. > > -----Original Message----- > From: Jens Geyer [mailto:[email protected]] > Sent: Sunday, April 19, 2015 7:14 PM > To: [email protected] > Subject: Re: String enums > > Ok, now I'm pretty sure I don't understand the problem. > Why do you have to change the API when you only want to map enums to strings > in the client? > > > > -----Ursprüngliche Nachricht----- > From: Jonathan Kanarek > Sent: Sunday, April 19, 2015 5:46 PM > To: [email protected] > Subject: RE: String enums > > I want to keep the server side as is and implement only client libraries. > If no one have a better idea, I guess I'll have to implement changes > on the server side as well. > > T. > > -----Original Message----- > From: Jens Geyer [mailto:[email protected]] > Sent: Sunday, April 19, 2015 6:22 PM > To: [email protected] > Subject: Re: String enums > >> How would you implement it without generating translation map? > That was my first thought, to be honest. What speaks against it? Or > maybe I just don't understand the problem right. > > > -----Ursprüngliche Nachricht----- > From: Jonathan Kanarek > Sent: Sunday, April 19, 2015 4:57 PM > To: [email protected] > Subject: String enums > > Hi, > I want to expose existing server which currently supports enums that > their values are strings. > How would you implement it without generating translation map? > > T. >
