Regarding optional vs required... sigh. It turns out that there actually is a third state, which I've take to calling "default". It's a weird legacy "feature" that I don't recommend anyone use. Do the smart thing and specify either required or optional specifically on your structs' fields.
Java distinguishes strings from binaries in the interface, despite the fact that they are passed on the wire in the same fashion. On Mon, Mar 5, 2012 at 10:35 AM, Anthony Molinaro < antho...@alumni.caltech.edu> wrote: > Hi, > > So I was looking at THRIFT-1475 and THRIFT-1532, both of which attempt > to fix some dialyzer warnings (warnings which I actually have yet to see > so we'll see if I can get some more information from the reporters). In > looking at what we generate now and thinking about things I came across > a couple of random issues which I thought warranted discussion. > > 1. It seems that when a requiredness is not set, that the erlang library > treats these fields as optional. Talking to a coworker he said, yeah > the java library does the sames thing. But looking at the cpp generator > the comments claim the default should be required. However, looking at > the various .thrift files in test, I see ManyOptionals.thrift which > uses the default. So which is correct is the default for a field to > be required or optional? Or is there some other meaning, like default > is required fields that can be undefined or something? > > 2. The second issue is around binary versus string. Based on my own > usage of thrift I know that when the server callback function receives > a record, any fields that were of type 'string' are actually binaries. > Now I can see why this might be the case as its more efficient to leave > them as a binary after they've been pulled off the wire, but not knowing > the history of the erlang bindings, I can't say for sure. Is the original > author(s) still on this list and want to comment on what the thinking > was there? Should it be changed so that 'string' in the definition results > in a 'string' sent to the receiving callback, while a 'binary' results in > things being left as 'binary'. This would not be a backward compatible > change but would probably be easier for people to deal with. > > Thanks, > > -Anthony > > -- > ------------------------------------------------------------------------ > Anthony Molinaro <antho...@alumni.caltech.edu> >
