El 16/03/2012 14:35, Adam D. Ruppe escribió:

>
> We introduce two new things to the language:
>
> 1) the @note(expression) attribute. You can put
> as many "notes" on a declaration as you want by
> simply listing them.
>


I like that.

I learned about annotations a couple years ago in two contexts:

- Web Services in Java and C#
- Hibernate in Java

They come very handy and are hard to beat with current language features.

[WebService]
public class Service : WebService
{
    [WebMethod]
    public string helloWorld() {
        return "Hello World";
    }
}

What coult be a similar D with annotations?:

@note(WebService)
class Service : WebService
{
    @note(WebMethod)
    string helloWorld() {
        return "Hello World";
    }
}

and have some CTFE stuff generate the magic?

On 17 March 2012 02:53, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 3/17/12, Kapps <opantm2+spam@gmail.com> wrote:
> > @WebForm("Account");
> > @PostTo("Services/CreateAccount")
> > @SecureOnly(true)
> > struct CreateAccountForm {
>
> That kind of turns D from a structural to a declarative language. :p
>

And that's awesome in many situations! :)

This also maps really well to games/tools/editors/script bindings. C# has this, and it's an invaluable language feature. It adds so much simplicity to the tools code.

What we're talking about here is subject-oriented programming: having the attributes get enclosed into objects, rather then objects enclosing attributes. And this is extremely useful, IMO.

On Sat, Mar 17, 2012 at 1:23 PM, Manu <turkeyman@gmail.com> wrote:
> On 17 March 2012 02:53, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>>
>> On 3/17/12, Kapps <opantm2+spam@gmail.com> wrote:
>> > @WebForm("Account");
>> > @PostTo("Services/CreateAccount")
>> > @SecureOnly(true)
>> > struct CreateAccountForm {
>>
>> That kind of turns D from a structural to a declarative language. :p
>
>
> And that's awesome in many situations! :)
>
> This also maps really well to games/tools/editors/script bindings. C# has this, and it's an invaluable language feature. It adds so much simplicity to the tools code.



-- 
Bye,
Gor Gyolchanyan.

On 2012-03-16 14:35, Adam D. Ruppe wrote:
> On the ride over here today, I had a thought that
> I think neatly solves the user defined attribute
> question.

I would love to have user defined attributes in D but I'm not completely like your approach. I would go with something more like Java annotations. This is how I would like user defined attributes to work.

Attributes can be applied to most declarations like: classes, fields, variables, functions, parameters and so on. Attributes are used with the following syntax:

@foo(key = "value", key2 = "value2) class Bar {}

"foo" is the name of the attribute. In the parentheses is a key-value list passed to the attribute. The values can be of any type available at compile time.

Attributes are defined as follows:

We add a new attribute called "@annotation" or "@attribute". This attribute is applied to a class or struct to make it an attribute:

@attribute class foo
{
    string key;
    string key2;
}

The keys the attribute accepts are declared in the class as either fields or methods (haven't decided yet). It's perfectly fine to have an attribute accepting no values which doesn't have to declare any keys:

@attribute class bar {}

If an attribute only accepts one value the name of the value needs to be "value":

@attribute class fooBar
{
    string value;
}

This allows to not have to specify the key when passing a value to the attribute:

@fooBar("asd") class Foo {}

Accessing information about attribute should be possible both during compile time and runtime. At compile time "__traits" can be used:

__traits(hasAttribute, bar, Foo); // returns true if the attribute "bar" as been applied to "Foo"

__traits(getAttribute, bar, key, Foo); // returns the value of the key "key"

This is all very similar to how it works in Java:

http://docs.oracle.com/javase/1.5.0/docs/guide/language/annotations.html

-- 
/Jacob Carlborg

On 3/16/2012 7:11 AM, Manu wrote:
> attribute myAttribute
> {
>    this(int something);
>
>    bool bNeedsAttention;
>
>    property void refresh(bool bRefresh) { bNeedsAttention = bRefresh; }
> }
>
> @myAttribute(10) int thing;
>
> thing.refresh = true;

Under the hood, where would that per-instance data be stored?

Compile-time annotations can be stored internally to the compiler, but per-instance runtime data? How is it connected to the instance? When is it constructed and destroyed?

On 17 March 2012 21:56, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/16/2012 7:11 AM, Manu wrote:
>
>> attribute myAttribute
>> {
>>   this(int something);
>>
>>   bool bNeedsAttention;
>>
>>   property void refresh(bool bRefresh) { bNeedsAttention = bRefresh; }
>> }
>>
>> @myAttribute(10) int thing;
>>
>> thing.refresh = true;
>>
>
> Under the hood, where would that per-instance data be stored?
>
> Compile-time annotations can be stored internally to the compiler, but per-instance runtime data? How is it connected to the instance? When is it constructed and destroyed?
>

In Java+C# it just lives in the class somewhere. Put it right beside the
attributed member, or maybe separate them into an attribute section at the
end of the class (to preserve structural layout). Construct along with the
class, I suppose the moment would be after member initialisation, but
before the constructor executes.
I wonder if it should only be allowed on classes/class members... adding
hidden data to a 'struct' almost defeats the purpose. Java doesn't have
'struct', so no problem. I wonder what C# does exactly...

On 17 March 2012 23:52, Manu <turkeyman@gmail.com> wrote:

> On 17 March 2012 21:56, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 3/16/2012 7:11 AM, Manu wrote:
>>
>>> attribute myAttribute
>>> {
>>>   this(int something);
>>>
>>>   bool bNeedsAttention;
>>>
>>>   property void refresh(bool bRefresh) { bNeedsAttention = bRefresh; }
>>> }
>>>
>>> @myAttribute(10) int thing;
>>>
>>> thing.refresh = true;
>>>
>>
>> Under the hood, where would that per-instance data be stored?
>>
>> Compile-time annotations can be stored internally to the compiler, but per-instance runtime data? How is it connected to the instance? When is it constructed and destroyed?
>>
>
> In Java+C# it just lives in the class somewhere. Put it right beside the
> attributed member, or maybe separate them into an attribute section at the
> end of the class (to preserve structural layout). Construct along with the
> class, I suppose the moment would be after member initialisation, but
> before the constructor executes.
> I wonder if it should only be allowed on classes/class members... adding
> hidden data to a 'struct' almost defeats the purpose. Java doesn't have
> 'struct', so no problem. I wonder what C# does exactly...
>

I tend to think of 'struct's as 'passive', and compile-time annotations would provide me with every use case I can imagine for my own purposes in the case of structs. classes seem far more likely to need stateful attributes.

On 3/17/2012 2:55 PM, Manu wrote:
> I tend to think of 'struct's as 'passive', and compile-time annotations would
> provide me with every use case I can imagine for my own purposes in the case of
> structs. classes seem far more likely to need stateful attributes.

I currently find the notion of runtime attribute state to be fraught with all kinds of unresolved and murky issues with no obvious answer:

1. construction/destruction
2. shared
3. const/immutable
4. thread locality
5. allocated statically or dynamically
6. shared library issues?

If the attribute is code, when does that code get run?

1. on initialization
2. on termination
3. on read
4. on write
5. what about read/write?

On 18 March 2012 03:10, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/17/2012 2:55 PM, Manu wrote:
>
>> I tend to think of 'struct's as 'passive', and compile-time annotations
>> would
>> provide me with every use case I can imagine for my own purposes in the
>> case of
>> structs. classes seem far more likely to need stateful attributes.
>>
>
> I currently find the notion of runtime attribute state to be fraught with all kinds of unresolved and murky issues with no obvious answer:
>
> 1. construction/destruction
>

After initialisation, before construction.

2. shared
>

How is this any different than for the class its self?

3. const/immutable
>

Inherit these properties.

4. thread locality
>

Same as class.

5. allocated statically or dynamically
>

I'd say dynamically if restricted to classes, but some suggested the syntax '@attribute struct/class MyAttribute { }', which could clarify the intent.

6. shared library issues?
>

If extern(D), then there should be no problems. If extern(C), then the
attributes would just appear like structure members. Assuming the layout
was documented (ie, in-order of appearance, at the end of the class), C/C++
could include them at the end of the class definition, and access them
directly as if usual classes. All that would be lost is the implicit
(compile time) association between the attribute and its associated class
member.
I don't think it's fair to expect a novel language feature to be supported
by C/C++ though.


If the attribute is code, when does that code get run?
>
> 1. on initialization
> 2. on termination
> 3. on read
> 4. on write
> 5. what about read/write?
>

I might go and read up on C# more thoroughly and get back to you... maybe
others here are already more familiar with C#'s attribute management?
I'm sure C# already answers all these questions. It has precisely the same
set of issues associated.

On 3/17/2012 6:39 PM, Manu wrote:
> I'm sure C# already answers all these questions. It has precisely the same set
> of issues associated.

C# doesn't have RAII, immutable, nor the notion of threadlocal/shared types.