We also made good experiences with that approach. I just want to add that we do the same with retvals - we always return a struct (or void) which has several advantages: - you can add more data at any time - possibility to retire old elements - ability to return a null value for a member is legal, returning null as function result is not
Have fun, JensG ________________________________ Von: Edward Capriolo Gesendet: 12.02.2015 04:49 An: [email protected] Betreff: Re: best practices for methods - to wrap arguments into struct or not? Yes, I believe so. Thrift does not support overloaded methods and thus it makes the methods in a service hard to evolve. I prefer to send a a single struct with all/mostly optional arguments. This way if service methods get new parameters the change does not cause a ripple of API breaking changes on the client. Otherwise you end up doing something like: v1 int method(int x); v2 int method(int x); int method_v2(int x, int y); I think this cleaner in the long run: v1 int method( methodStruct); v2 int method( methodStruct); This is because structs have optional members but functions do no. even though they are marked optional no language supports them even languages that theoretically could support optional arguments like python. On Wed, Feb 11, 2015 at 10:22 PM, Denis Samoilov <[email protected]> wrote: > hello Thrift Community! > > Is there best practice to wrap function params into struct? like: > struct InfoRequest { > 1: required bool getActive > 2: required i32 logLimit > } > ClientsInfoList getExtendedClientsInfo(1: InfoRequest params) > vs > ClientsInfoList getExtendedClientsInfo(1: bool getActive, 2: i32 logLimit) > > > > because this way i can add more optional (with default values) params in > future without breaking backward compatibility, like > struct InfoRequest { > 1: required bool getActive > 2: required i32 logLimit > 3: optional i32 newParam > } > > Thank you! >
