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