As no one else commented I just wanted to point out that probably both 2a
and 2b are acceptable as long the implementation is generic enough to avoid
duplicated code on different generators.
I believe 2a should use warnings to avoid restricting current working IDL's
and 2b could give errors directl
2a sounds good to me, since it is consistent. That could be important
for projects that ship thrift files intended for users who want to
build their own clients, for example.
Another discussion could be to catch the same types of issues for
field and enum names. But that is... another discussion :
So most people agree: no aliases (shame ;) )
Soo... I see two potential changes as a result of this discussion:
1. Add i8 for consistency
2. Add dictionary of reserved keywords and validate all type and
variable names against it
a. one global dictionary containing merge of keywords of all
'long' on most 32-bit platforms is 32-bit. 'long' on Max
and Linux 64-bit is 64-bits, but 'long' on Win64 is 32-bits.
True. Another point against it.
Hi,
Out of curiosity, what kinds of errors did you see from this?
http://stackoverflow.com/questions/27216939/apache-thrift-c-typedef-issue
Not me personally, but I remember having seen a similar question a few weeks
ago. For some reason people seem to like their ints more than i32. It's not
s/is a service/is a better service/ ;-)
On Tue, Dec 2, 2014 at 3:01 PM, Stig Bakken wrote:
> @Konrad: My point about errors came to mind because I had just been
> working on the JSON generator, where type names are strings. I guess
> it won't apply if the aliases are only present at parse time.
>
@Konrad: My point about errors came to mind because I had just been
working on the JSON generator, where type names are strings. I guess
it won't apply if the aliases are only present at parse time.
However, these vague type definitions from C / Java have been the
cause of a lot of portability hea
@Konrad, that might be a good idea to have a 'reserved type and members
names', perhaps a little table on each generator/parser.
So the c++ generator can throw a warning or error before it gets to the
compiler (e.g. gcc), since 'typedef i32 int' might work in some languages
but it's definitely not
I was assuming aliases would only be present at parsing time. I to
prefer iX notation, I like to be explicit. Yet I can imagine a lot of
users, who don't care about bits and bytes, they just want int. Or they
want to make IDL look more like Java/C# ;)
I'd not try to detect all 'typedef i32 int
FWIW, I agree with Randy. There is value to being able to directly
compare two type names through simple equality, with aliases you will
get situations where you need code like "are_these_types_the_same(t1,
t2)".
On Mon, Dec 1, 2014 at 2:21 PM, Randy Abernethy wrote:
> One of the things I love
r 'short' and 'int', but the
platforms where those are 'unusual' sizes tend to be more unusual
themselves. Allegedly, old Cray machines made all the primitives 64-bit,
even char.
Randy Abernethy wrote on 12/01/2014 08:10:18 AM:
> From: Randy Abernethy
> To: "
GMT+01:00)
> Do: dev@thrift.apache.org
> Temat: Re: i32 vs int
>
> One of the things I love about Thrift is its simple IDL. No aliases
> just simple self describing types (i8, i16, etc). We presently have
> one keyword for each feature of the IDL. I think the Pandora's box
> analogy is a g
There's no i8 but byte, which creates inconsistency ;)
Oryginalna wiadomość
Od: Randy Abernethy
Data:01.12.2014 14:21 (GMT+01:00)
Do: dev@thrift.apache.org
Temat: Re: i32 vs int
One of the things I love about Thrift is its simple IDL. No aliases
just simple
One of the things I love about Thrift is its simple IDL. No aliases
just simple self describing types (i8, i16, etc). We presently have
one keyword for each feature of the IDL. I think the Pandora's box
analogy is a good one. It is hard work keeping things simple.
On Mon, Dec 1, 2014 at 12:09 AM,
Out of curiosity, what kinds of errors did you see from this?
- Stig
On Mon, Dec 1, 2014 at 1:18 AM, Jens Geyer wrote:
> Hi *,
>
> I have found people multiple times doing things like this, ending up with
> strange errors.
>
> typedef i32 int
>
> What about making it legal and allowing in
Hey,
I'd go with aliases, including 'short' and 'long' and 'i8' just to keep
everything consistent :)
Best,
Konrad
W dniu 2014-12-01 o 01:18, Jens Geyer pisze:
Hi *,
I have found people multiple times doing things like this, ending up with
strange errors.
typedef i32 int
What about
Hi *,
I have found people multiple times doing things like this, ending up with
strange errors.
typedef i32 int
What about making it legal and allowing int as an built-in alias for i32?
Or should we add some kind of warning instead?
Or would either one of these just open pandora’s box?
17 matches
Mail list logo
