Hi *,
regarding the binary: I would vote to make the binary a real base type, as
stated on http://wiki.apache.org/thrift/ThriftTypes. I'm just not quite sure
what this change could possibly break.
JensG
-----Ursprüngliche Nachricht-----
From: Anthony Molinaro
Sent: Monday, March 05, 2012 7:35 PM
To: dev@thrift.apache.org
Subject: History and usage of erlang library
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>
