History and usage of erlang library

[Anthony Molinaro <an...@alumni.caltech.edu>]

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                           <an...@alumni.caltech.edu>

Re: History and usage of erlang library

[Bryan Duxbury <br...@rapleaf.com>]

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 <
anthonym@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                           <an...@alumni.caltech.edu>
>

Re: History and usage of erlang library

[Jens Geyer <je...@hotmail.com>]

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                           <an...@alumni.caltech.edu>