User Defined Attributes

David Nadlinger see at klickverbot.at
Tue Nov 6 10:17:48 PST 2012


On Tuesday, 6 November 2012 at 18:06:15 UTC, Walter Bright wrote:
> On 11/6/2012 10:01 AM, David Nadlinger wrote:> On Tuesday, 6 
> November 2012 at 17:51:28 UTC, Walter Bright wrote:
> >> On 11/6/2012 9:32 AM, David Nadlinger wrote:
> >>> service Calculator {
> >>>    i32 calculate(1:i32 a, 2:i32 b, 3:Op op)
> >>
> >> What does this mean? That 'a' is the first parameter and has
> type i32?
> >
> > It means that ›a‹ has type i32
>
> Ok, but a type is not a UDA <g>.

That was never my point. I could have also just said »Parameters 
to Thrift RPC methods have numerical IDs«, but I though a code 
example might be clearer. Apparently, I was wrong. ;)

> Why isn't 'a' the ID?
a is just a name used for documentation purposes – they show up 
in target language code generated by the Thrift compiler from the 
IDL file, for implementations which rely on code generation [1].

On the wire, all struct fields and method parameters are tagged 
with integer IDs, and those are actually what's used for 
(de-)serializations. This use of IDs is a common feature of 
»high-performance« RPC protocols designed to support interface 
evolution, e.g. Google's protobuf makes use of them as well.

David


[1] The compiler module for D only translates type and service 
definitions to D structs/interfaces, the rest happens using CTFE 
magic, which enables use of Thrift without writing .thrift files 
(in fact, they can be generated _from_ D code using CTFE). In 
theory, the compiler could be completely replaced using 
ImportStatements and CTFE, but I never got that out of the 
prototype stage due to compiler bugs.


More information about the Digitalmars-d-announce mailing list