November 06, 2012 Re: User Defined Attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 2012-11-06 17:22, Walter Bright wrote: > Consider that you can use a tuple generated elsewhere for a UDA: > > [tp] void foo(); > > where tp is a tuple. You can even grab the attributes from another > symbol, turn them into a tuple, and apply the tuple as an attribute to a > new symbol. Tuples can, of course, be sliced and concatenated. > > In other words, by using tuples, you can "encapsulate" what the > attributes expand to in the same way you can change target code by > changing the definition of user defined types. Then allow something like this: @(tp) Or @foo(tp) -- /Jacob Carlborg |
November 06, 2012 Re: User Defined Attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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>. > and is the parameter with ID 1. The parameter > list could have also been (42:i32 a, 5:i32 b, 1:Op op). If no ids are specified, > negative ones are auto-assigned by the compiler, starting from -1. Why isn't 'a' the ID? |
November 06, 2012 Re: User Defined Attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 11/6/2012 9:52 AM, bearophile wrote:
> // Case3 (uncommon)
> void main() {
> auto data = [0, 1, 2, 3];
> foreach (@copy x; data)
> writeln(++x);
> }
x is a value type, and it is already copied. And if you did want to copy it,
foreach (x; data)
{ auto copy = x;
writeln(++copy);
}
I don't see what the annotation buys you, even if it could be made to work.
|
November 06, 2012 Re: User Defined Attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | On 2012-11-06 18:00, David Nadlinger wrote: > Yes, it is nice to have a working prototype indeed. What is not so nice > in my opinion, however, is that this first prototype straight to Git > master, without any prior evaluation, at a time where the general goal > is to stabilize the language. Yes, very good point. I don't see why this hasn't been done before, it's dead easy. Just use: $ git checkout -b uda # code $ git commit -a -m "Add support for user defined attributes" $ git push origin uda Walter, why aren't you using branches for these kind of things? -- /Jacob Carlborg |
November 06, 2012 Re: User Defined Attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On 11/6/2012 10:01 AM, Jacob Carlborg wrote: > What's the issue with the name scoping system? That the user defined attributes > will conflict with already existing attributes? You'll have the same problem > with keywords. Perhaps that's why attributes where created, to have a new > namespace for keywords. Even if they might not be the same internally for the > compiler it's the same for the user/developer. Then all UDAs must exist in some shared global name space, and scoping and encapsulation becomes like it is in C, i.e. every_body_writes_their_names_like_this and hopes it doesn't conflict with someone else's names. |
November 06, 2012 Re: User Defined Attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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. |
November 06, 2012 Re: User Defined Attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 2012-11-06 19:16, Walter Bright wrote: > Then all UDAs must exist in some shared global name space, and scoping > and encapsulation becomes like it is in C, i.e. > every_body_writes_their_names_like_this and hopes it doesn't conflict > with someone else's names. No, what's the difference between this: @every_body_writes_their_names_like_this int a; And ["every_body_writes_their_names_like_this"] int a; None. -- /Jacob Carlborg |
November 06, 2012 Re: User Defined Attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Le 06/11/2012 19:02, Walter Bright a écrit :
> On 11/6/2012 9:34 AM, dennis luehring wrote:
>> can't you please give us a bad-usage example why it is/should be
>> forbidden to
>> use UDA on parameters (and please - we are not talking about pure, in,
>> out and
>> stuff like that)
>
> I believe this is the wrong question. For a new feature, the question
> should be "why should it be included", not "why shouldn't it be included."
>
No. It is needed to annotate symbols, uses cases are numerous. Now, if an exception is added, the exception should be justified.
|
November 06, 2012 Re: User Defined Attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Tuesday, 6 November 2012 at 18:16:15 UTC, Walter Bright wrote:
> Then all UDAs must exist in some shared global name space, and scoping and encapsulation becomes like it is in C, i.e. every_body_writes_their_names_like_this and hopes it doesn't conflict with someone else's names.
You are right, UDAs must definitely leverage D's module system for encapsulation/disambiguation. Use of string literals (which are intrinsically »global«) as annotations needs to be explicitly discouraged.
David
|
November 06, 2012 Re: User Defined Attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | Le 06/11/2012 19:19, Jacob Carlborg a écrit :
> On 2012-11-06 19:16, Walter Bright wrote:
>
>> Then all UDAs must exist in some shared global name space, and scoping
>> and encapsulation becomes like it is in C, i.e.
>> every_body_writes_their_names_like_this and hopes it doesn't conflict
>> with someone else's names.
>
> No, what's the difference between this:
>
> @every_body_writes_their_names_like_this int a;
>
> And
>
> ["every_body_writes_their_names_like_this"] int a;
>
> None.
>
Let me suggest what have already been suggested by others :
@identifier(parameters)
identifier is resolved as any identifier is. It allow for disambiguation. It also allow for a lib to provide its own attributes types without colliding which other (it is easy to filter the tuple for attribute with the right type).
|
Copyright © 1999-2021 by the D Language Foundation