Personally I defer to the community at this point as I'm not so actively involved in development these days - we're open source! If you feel strongly about this you should definitely feel welcome to join the dev list and discuss it, or even sketch out a patch.
My gut reaction to adding "lite" is that it would probably increase confusion, as we'd now have another special keyword to learn and still have the same default behavior (which we need for backwards-compatibility, to your point). Better documentation seems like the fastest and simplest route to greater sanity, in my opinion. On 4/7/12 9:42 AM, "Piscium" <[email protected]> wrote: >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?
