On 5 April 2012 21:04, Mark Slee <[email protected]> wrote: > Your technical analysis is correct, as well as the historical inference! > The "required" and "optional" modifiers were not present in the first > version of the IDL, and the original intent was to make using Thrift as > lightweight and transparent as possible. There was an assumption that many > clients would be written in scripting languages, where wrapping everything > up in setters/getters would feel unnatural - we didn't want to make > modifying fields require a function call (via a setter) or require the > programmer to manually maintain all the isset flags. So all fields would > be sent regardless of isset, with one important exception - languages with > nil/null don't send empty fields. > > The required/optional keywords were added later to make it easier to > automate some of this checking, and to make it possible for clients in > null-less languages (i.e. C++) to explicitly omit optional fields. > > The downside to this approach is that it does make the default behavior > more opaque. Hope that sheds some light on it.
Hi Mark, Thanks a lot for that. I think it is very helpful to have a bit of knowledge about the history of Thrift as well as the ideas that guided its development, as it makes easier to understand it. Now one suggestion. The current situation with the field qualifiers (optional/required) is not ideal. A sign of that is that I thought that a field without a qualifier was optional while Rush thought it was required, and neither of us was correct, as it actually has different semantics (for historical reasons, as you explained). Changing the parser to disallow a field definition without a qualifier does not seem a good idea as it would break backward compatibility. A better solution IMO would be to add an extra qualifier, that could be named, for example, "lite". A field definition without a qualifier would be considered to have the default "lite" qualifier, and a "lite" field would be exactly the same as currently a field without a qualifier (i. e. always sent on transmission and not causing a exception if not present on reception for C++, and whatever default behaviour is currently used for the other supported languages). Obviously this would require code changes to the lexical analyser, parser and code generators for all the supported languages, so the question could be asked if the benefits justify the cost. Alternatively the current behaviour could just be explained on the wiki with 99.99% less effort! What do you think?
