I think it's generally an interesting idea but it definitely strays into the gray area of mixing application functionality with transport/protocol functionality. A main concern is definitely implementation coverage across languages. I'd definitely want to avoid getting into things like regex matching here. It's also unclear if there would always be one standard way in which clients would want to handle these errors. Leaving this in the application code lets you take appropriate action for the error on a case-by-case basis, whereas building this into Thrift would require one exception/error model for handling these.
This also sounds like a good use case for the custom modifier extensions that dreiss has been working on. Cheers, mcslee -----Original Message----- From: Bryan Duxbury [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2008 6:35 PM To: [email protected] Subject: Idea: Validations I was thinking today about how it would be useful to have some the option to do some kinds of validations on field values in Thrift objects. For instance, say you have a struct with a field "required string blah". You've managed to specify that it must be part of the struct, but nothing else. What if you also want to demand that it's a non-empty string? Or if it needs to be of a certain length? These are things that would make the generated code a lot more convenient to use at times. There are potentially a lot of these validations you could create, but most of them would be pretty trivial to implement in multiple languages. String, byte[], and collection length would be one simple one. Greater/less than for numeric fields would be another. One potentially tricky but awesome one would be "must match regex" validation on string fields. Clearly these validations might have a performance implication, so you probably wouldn't expect the to be run by default on all structs, though it'd be sensible to be able to enable and disable them globally so you can switch from development to production mode easily. You could always have access to the functionality via a public validate() method that would tell you true or false if the struct contained the proper fields. Do others think this would be interesting? It'd potentially introduce a lot of work in making sure each different validation was implemented across languages, but that would be mitigated by not having to have your application developers write the validation code in all the languages you use. -Bryan
