www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - User Defined Attributes (UDA) in Phobos/druntime

reply Jacob Carlborg <doob me.com> writes:
This was brought up in the thread reviewing std.serialization:

http://forum.dlang.org/thread/adyanbsdsxsfdpvoozne forum.dlang.org

Currently we haven't started to use UDA's in Phobos or druntime yet (as 
far as I know). I would like to start a discussion about putting out 
some guidelines for using UDA's in Phobos/druntime.

I've created a small module that handles UDA's:

https://github.com/jacob-carlborg/orange/blob/master/orange/core/Attribute.d

The idea is to have a kind of meta UDA called "attribute". This 
attribute needs to be attached to all structs, enums and so on that is 
to be used as an attribute.

The module provides a template (getAttributes) to get, by default, only 
those values attached to a given symbol that is an attribute. That is, 
marked with the "attribute" attribute.

So my suggestion for guidelines are:

* Only types with the "attribute" UDA is to be used as attributes
* In general, don't use primitive values as a UDA

Don't use this

 (3) int a;

Use this:

 attribute struct foo { int b; }

 foo(3) int a;

* A user defined type marked with "attribute" should not be used for 
something else than an UDA

* All attributes use camel case names

If we agree on this and that we need a module like the one above I think 
it should be added to druntime. The reason for that is that we most 
likely want to use UDA's in druntime and not only in Phobos. Example, if 
we ever get std.serialization into Phobos we would want to mark Thread 
and similar structs/classes as "nonSerialized".

Thoughts?

-- 
/Jacob Carlborg
Jun 11 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/11/2013 12:00 AM, Jacob Carlborg wrote:
 Thoughts?

I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions.
Jun 11 2013
next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 11 June 2013 at 07:36:44 UTC, Walter Bright wrote:
 On 6/11/2013 12:00 AM, Jacob Carlborg wrote:
 Thoughts?

I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions.

Wise words. +1
Jun 11 2013
prev sibling next sibling parent reply "Jonas Drewsen" <nospam4321 hotmail.com > writes:
On Tuesday, 11 June 2013 at 07:36:44 UTC, Walter Bright wrote:
 On 6/11/2013 12:00 AM, Jacob Carlborg wrote:
 Thoughts?

I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions.

Though I might not agree with this suggested meta-attribute thing I really think that serialization screams for using attributes to mark fields/classes as serializable. Would be sad not to have them. Jacob: Would it be doable to refactor the attribute magic in std.serialization into a separate module that could be provided as 3rd party extension to std.serialization until phobos itself is ready for attributes? /Jonas
Jun 11 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-11 11:07, Jonas Drewsen wrote:

 Jacob: Would it be doable to refactor the attribute magic in
 std.serialization into a separate module that could be provided as 3rd
 party extension to std.serialization until phobos itself is ready for
 attributes?

The generic code for attributes is located in orange.core.Attribute, this can be inlined or removed. The actual attributes them self are located in orange.serialization.Serializable. The library is perfectly usable without UDA's. The old template mixins are still available. If __traits(getAttributes) is not allowed in Phobos then I have to remove the code that checks for UDA's. -- /Jacob Carlborg
Jun 11 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-11 11:58, Jacob Carlborg wrote:

 The library is perfectly usable without UDA's. The old template mixins
 are still available.

The template mixins basically emulates UDA's. -- /Jacob Carlborg
Jun 11 2013
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Tuesday, 11 June 2013 at 07:36:44 UTC, Walter Bright wrote:
 On 6/11/2013 12:00 AM, Jacob Carlborg wrote:
 Thoughts?

I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions.

I disagree - if you wait for UDAs to appear more in user-code, you'll end up with multiple conventions for using them. If they are used in Phobos/druntime first, users will conform to the Phobos/druntime convention.
Jun 11 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 11 June 2013 at 14:59:44 UTC, Idan Arye wrote:
 On Tuesday, 11 June 2013 at 07:36:44 UTC, Walter Bright wrote:
 On 6/11/2013 12:00 AM, Jacob Carlborg wrote:
 Thoughts?

I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions.

I disagree - if you wait for UDAs to appear more in user-code, you'll end up with multiple conventions for using them.

That's what we want, surely: Multiple conventions appear, then with the benefit of hindsight the best can be selected for phobos.
Jun 11 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 Jun 2013 05:58:50 -0400, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-11 11:07, Jonas Drewsen wrote:

 Jacob: Would it be doable to refactor the attribute magic in
 std.serialization into a separate module that could be provided as 3rd
 party extension to std.serialization until phobos itself is ready for
 attributes?

The generic code for attributes is located in orange.core.Attribute, this can be inlined or removed. The actual attributes them self are located in orange.serialization.Serializable. The library is perfectly usable without UDA's. The old template mixins are still available. If __traits(getAttributes) is not allowed in Phobos then I have to remove the code that checks for UDA's.

I think we can have and use UDAs in Phobos without yet having to create a guideline. Note that there is lots of experience with attributes in other languages that we can draw from. Most people here have written in at least one other language that uses them. I have no problem with std.serialization using attributes, even if there is no "official" guide. -Steve
Jun 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 11 June 2013 at 07:36:44 UTC, Walter Bright wrote:
 On 6/11/2013 12:00 AM, Jacob Carlborg wrote:
 Thoughts?

I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions.

That sound good, but the complete opposite have been done every single time. That raise the question of consistency.
Jun 12 2013
prev sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Wednesday, 12 June 2013 at 07:46:31 UTC, deadalnix wrote:
 On Tuesday, 11 June 2013 at 07:36:44 UTC, Walter Bright wrote:
 On 6/11/2013 12:00 AM, Jacob Carlborg wrote:
 Thoughts?

I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions.

That sound good, but the complete opposite have been done every single time. That raise the question of consistency.

And that's why Walter wants to avoid repeating the same mistakes again.
Jun 12 2013
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Tuesday, 11 June 2013 at 07:00:29 UTC, Jacob Carlborg wrote:
 The idea is to have a kind of meta UDA called "attribute". This 
 attribute needs to be attached to all structs, enums and so on 
 that is to be used as an attribute.

 The module provides a template (getAttributes) to get, by 
 default, only those values attached to a given symbol that is 
 an attribute. That is, marked with the "attribute" attribute.

 So my suggestion for guidelines are:

 * Only types with the "attribute" UDA is to be used as 
 attributes
 * In general, don't use primitive values as a UDA

 Don't use this

  (3) int a;

 Use this:

  attribute struct foo { int b; }

  foo(3) int a;

 * A user defined type marked with "attribute" should not be 
 used for something else than an UDA

 * All attributes use camel case names

Camel case has two versions - and I suggest to use the one that starts with capital - that is, ` attribute struct FooBar` and not ` attribute struct fooBar`. This will save a lot of trouble when we want to add new keyword attributes. The exception is the `attribute` attribute itself - in the future we might want to make it a keyword attribute(so we can, for example, enforce it's usage for attributes), and it that case it would be helpful if all UDAs already use it.
Jun 11 2013
prev sibling next sibling parent reply "QAston" <qaston gmail.com> writes:
On Tuesday, 11 June 2013 at 07:00:29 UTC, Jacob Carlborg wrote:
 This was brought up in the thread reviewing std.serialization:

 http://forum.dlang.org/thread/adyanbsdsxsfdpvoozne forum.dlang.org

 Currently we haven't started to use UDA's in Phobos or druntime 
 yet (as far as I know). I would like to start a discussion 
 about putting out some guidelines for using UDA's in 
 Phobos/druntime.

 I've created a small module that handles UDA's:

 https://github.com/jacob-carlborg/orange/blob/master/orange/core/Attribute.d

 The idea is to have a kind of meta UDA called "attribute". This 
 attribute needs to be attached to all structs, enums and so on 
 that is to be used as an attribute.

 The module provides a template (getAttributes) to get, by 
 default, only those values attached to a given symbol that is 
 an attribute. That is, marked with the "attribute" attribute.

 So my suggestion for guidelines are:

 * Only types with the "attribute" UDA is to be used as 
 attributes
 * In general, don't use primitive values as a UDA

 Don't use this

  (3) int a;

 Use this:

  attribute struct foo { int b; }

  foo(3) int a;

 * A user defined type marked with "attribute" should not be 
 used for something else than an UDA

 * All attributes use camel case names

 If we agree on this and that we need a module like the one 
 above I think it should be added to druntime. The reason for 
 that is that we most likely want to use UDA's in druntime and 
 not only in Phobos. Example, if we ever get std.serialization 
 into Phobos we would want to mark Thread and similar 
 structs/classes as "nonSerialized".

 Thoughts?

I agree that attributes should have types - that way it's easily recognizable what are they for in code. "Anonymous" attributes seem to me to be sort of like "you can throw ANYTHING in c++" feature - it's there, but probably without a sane use case. Could you explain to me what's the benefit of the attribute convention you introduce? It seems non-obvious to me.
Jun 11 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-11 18:12, QAston wrote:

 I agree that attributes should have types - that way it's easily
 recognizable what are they for in code. "Anonymous" attributes seem to
 me to be sort of like "you can throw ANYTHING in c++" feature - it's
 there, but probably without a sane use case.
 Could you explain to me what's the benefit of the  attribute convention
 you introduce? It seems non-obvious to me.

It shows the intent of the type. D both have a keywords to indicate an interface and an abstract class. In C++ interfaces and abstract classes are possible as well, but there's no real way to tell that a given class is actually supposed to be used as an interface. I was kind of disappointed with the way D implemented UDA's. Just dump any value/type to a symbol. -- /Jacob Carlborg
Jun 11 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-06-11 23:04, QAston wrote:

 Ok, i see the point now, thanks :). Maybe it'd be worth to enforce that
 convention on a language level, let's say: only types with  attribute
 can be used as UDA. One reason for making that restriction is that when
 there's more than a one way of doing something people will do that using
 all the ways possible. This may be a problem to code which uses many
 libraries simultanously - your utility functions will not interoperate
 with UDAs made by someone else.

Yes, I would like to have the language enforce this. My utility function fetches by default types that are marked with attribute. You can add flag when calling the function to fetch all UDA's.
 BTW I've just found one use case for anonymous UDA:
  (Enum.Entry) is verbose, the question is: "Is it useful enough to keep
 it, or maybe having single convention is better?"

Is it possible to attach a UDA to an enum member? Or is it possible to figure out that it's an enum member and check if the enum itself has attribute attached to it? -- /Jacob Carlborg
Jun 11 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-06-12 14:29, Andrej Mitrovic wrote:

 But without this you lose the ability to customize. I don't like just
 "tagging" something, I like D's ability where you can actually
 customize the UDA, for example:

 -----
 import std.typetuple;

 struct Server
 {
      string url;
 }

 struct Config
 {
       (Server("http://foo.bar")) string name;
       (Server("http://doo.bar")) string[] items;
 }

 template GetAttributes(T...) if (T.length == 1)
 {
      alias GetAttributes = TypeTuple!(__traits(getAttributes, T[0]));
 }

 void main()
 {
      Config config;

      alias attribs = GetAttributes!(config.name);

      static if (attribs.length && is(typeof(attribs[0]) == test.Server))
      {
          pragma(msg, attribs[0]);
      }
 }
 -----

 Thanks to CTFE we can tag a field with a struct that may have any
 state. All you have to do in the library code is to first check if any
 of the attributes is an "attribute type (a struct of some sort)" that
 you recognize, and then read its state.

As far as I know other language allows UDA's to be of any type/value. Java uses the annotation annotation on an interface and in C# classes with System.Attribute as the base class are used. -- /Jacob Carlborg
Jun 12 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, June 11, 2013 16:48:13 Idan Arye wrote:
 Camel case has two versions - and I suggest to use the one that
 starts with capital

The term pascal case is frequently used when referring to the variant of camelcase which starts with a capital letter. - Jonathan M Davis
Jun 11 2013
prev sibling next sibling parent "QAston" <qaston gmail.com> writes:
On Tuesday, 11 June 2013 at 20:31:22 UTC, Jacob Carlborg wrote:
 On 2013-06-11 18:12, QAston wrote:

 I agree that attributes should have types - that way it's 
 easily
 recognizable what are they for in code. "Anonymous" attributes 
 seem to
 me to be sort of like "you can throw ANYTHING in c++" feature 
 - it's
 there, but probably without a sane use case.
 Could you explain to me what's the benefit of the  attribute 
 convention
 you introduce? It seems non-obvious to me.

It shows the intent of the type. D both have a keywords to indicate an interface and an abstract class. In C++ interfaces and abstract classes are possible as well, but there's no real way to tell that a given class is actually supposed to be used as an interface. I was kind of disappointed with the way D implemented UDA's. Just dump any value/type to a symbol.

Ok, i see the point now, thanks :). Maybe it'd be worth to enforce that convention on a language level, let's say: only types with attribute can be used as UDA. One reason for making that restriction is that when there's more than a one way of doing something people will do that using all the ways possible. This may be a problem to code which uses many libraries simultanously - your utility functions will not interoperate with UDAs made by someone else. BTW I've just found one use case for anonymous UDA: (Enum.Entry) is verbose, the question is: "Is it useful enough to keep it, or maybe having single convention is better?" Certainly, there's no need to have arbitrary types in attributes like UnawareClass because you can do TakeUnaware!(UnawareClass) instead. The other way around would be to operate on SerializationAttribute specific to the lib so you can fetch only the attributes you're interested in easily.
Jun 11 2013
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Tuesday, 11 June 2013 at 21:04:40 UTC, QAston wrote:
 The other way around would be to operate on 
  SerializationAttribute specific to the lib so you can fetch 
 only the attributes you're interested in easily.

How about passing template arguments to ` attribute` to determine what libraries the UDA it declares belong to? Here is an example implementation: https://gist.github.com/someboddy/5762072
Jun 11 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/11/13, Jacob Carlborg <doob me.com> wrote:
 I was kind of disappointed with the way D implemented UDA's. Just dump
 any value/type to a symbol.

But without this you lose the ability to customize. I don't like just "tagging" something, I like D's ability where you can actually customize the UDA, for example: ----- import std.typetuple; struct Server { string url; } struct Config { (Server("http://foo.bar")) string name; (Server("http://doo.bar")) string[] items; } template GetAttributes(T...) if (T.length == 1) { alias GetAttributes = TypeTuple!(__traits(getAttributes, T[0])); } void main() { Config config; alias attribs = GetAttributes!(config.name); static if (attribs.length && is(typeof(attribs[0]) == test.Server)) { pragma(msg, attribs[0]); } } ----- Thanks to CTFE we can tag a field with a struct that may have any state. All you have to do in the library code is to first check if any of the attributes is an "attribute type (a struct of some sort)" that you recognize, and then read its state.
Jun 12 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 12 June 2013 at 12:29:53 UTC, Andrej Mitrovic wrote:
 On 6/11/13, Jacob Carlborg <doob me.com> wrote:
 I was kind of disappointed with the way D implemented UDA's. 
 Just dump
 any value/type to a symbol.

But without this you lose the ability to customize. I don't like just "tagging" something, I like D's ability where you can actually customize the UDA, for example:

Both are 100% orthogonal
Jun 12 2013
prev sibling next sibling parent "QAston" <qaston gmail.com> writes:
On Wednesday, 12 June 2013 at 00:42:24 UTC, Idan Arye wrote:
 How about passing template arguments to ` attribute` to 
 determine what libraries the UDA it declares belong to?

 Here is an example implementation: 
 https://gist.github.com/someboddy/5762072

Yes, I think something like this solves interoperation issues.
Jun 12 2013
prev sibling parent "QAston" <qaston gmail.com> writes:
On Wednesday, 12 June 2013 at 06:46:06 UTC, Jacob Carlborg wrote:
 Yes, I would like to have the language enforce this. My utility 
 function fetches by default types that are marked with 
  attribute. You can add flag when calling the function to fetch 
 all UDA's.

 BTW I've just found one use case for anonymous UDA:
  (Enum.Entry) is verbose, the question is: "Is it useful 
 enough to keep
 it, or maybe having single convention is better?"

Is it possible to attach a UDA to an enum member? Or is it possible to figure out that it's an enum member and check if the enum itself has attribute attached to it?

Accrding to this http://dpaste.dzfl.pl/728872fa it's not possible to attach an UDA to enum member. I think that what you propose, together with parametrisation made by IdanArye to your attribute definition is a nice compromise for now. It allows reuse of utils and interoperation, sets up a convention to follow and does not enforce language changes. But it will only work if it's going to be in phobos for example as std.attribute. In my opinion such compromise would be easier to get into the language than fully enforcing the convention and I think it's very important to have some form of UDAs for serialization just for users' convenience.
Jun 12 2013