www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Custom attributes C#

reply Sclytrack <sclytrack pi.be> writes:


public class MyCustomAttribute:Attribute
{
  public MyCustomAttribute( string text)
  {
   }
  ...
}


class MyClass
{
  [MyCustom("my text")]
  void DoStuff()
  {
  }
}

The attributes can then be retrieved by system reflection. An attribute is
a class thus can contain code.


I was thinking of something similar in D, but simpler

attribute published;  // published would then be an attribute.

class Window
{
  attr(published) void caption(char [] text)
  {
  }
}

__traits( allAttributes, )


and maybe dropping the two underscores in the __traits

#d.lounge  Arthur, give Zuu a cookie.
Sep 26 2007
next sibling parent DavidL <davidl 126.com> writes:
Sclytrack Wrote:



 
 public class MyCustomAttribute:Attribute
 {
   public MyCustomAttribute( string text)
   {
    }
   ...
 }
 
 
 class MyClass
 {
   [MyCustom("my text")]
   void DoStuff()
   {
   }
 }
 
 The attributes can then be retrieved by system reflection. An attribute is
 a class thus can contain code.
 
 
 I was thinking of something similar in D, but simpler
 
 attribute published;  // published would then be an attribute.
 
 class Window
 {
   attr(published) void caption(char [] text)
   {
   }
 }
 
 __traits( allAttributes, )
 
 
 and maybe dropping the two underscores in the __traits
 
 #d.lounge  Arthur, give Zuu a cookie.


I've proposed something about naming a scope. 
scope("myattribute")void caption(char [] text){}
there must be some more general thing. 
Maybe alias is a better naming

alias("myattribute") void caption(char[] text){}
alias("myvar") int var;
Sep 26 2007
prev sibling next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 9/26/07, Sclytrack <sclytrack pi.be> wrote:




Please could you explain this for the benefit of those of us who do
Sep 26 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Janice Caron wrote:

 On 9/26/07, Sclytrack <sclytrack pi.be> wrote:




 
 Please could you explain this for the benefit of those of us who do



class Foo
{
    [SerialiseAs("bar")] int _bar;
    [DontSerialiseAtAll] void* _someCachedThing;
}

class ControllerWidget
{
    [GuiLabel("First Name"),GuiControl("TextBox")]
    string firstName;
    [GuiLabel("Last Name"),GuiControl("TextBox")]
    string lastName;

    [GuiLabel("Update records"),GuiControl("Button")]
    void update() { ... }
}

	-- Daniel
Sep 27 2007
parent reply "Janice Caron" <caron800 googlemail.com> writes:
This is obviously some strange usage of the word "explain" that I
wasn't previously aware of :-(

Any chance anyone could explain what that means? Square brackets mean
array access to me, so just sticking function calls in square brackets
where it would be a syntax error to do so does not really constitute
an explanation in my book.
Sep 27 2007
next sibling parent Regan Heath <regan netmail.co.nz> writes:
Janice Caron wrote:

 This is obviously some strange usage of the word "explain" that I
 wasn't previously aware of :-(
 
 Any chance anyone could explain what that means? Square brackets mean
 array access to me, so just sticking function calls in square brackets
 where it would be a syntax error to do so does not really constitute
 an explanation in my book.


I'm guessing:
http://en.wikipedia.org/wiki/.NET_metadata

Regan
Sep 27 2007
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Janice Caron wrote:

 This is obviously some strange usage of the word "explain" that I
 wasn't previously aware of :-(
 
 Any chance anyone could explain what that means? Square brackets mean
 array access to me, so just sticking function calls in square brackets
 where it would be a syntax error to do so does not really constitute
 an explanation in my book.


It's a concept similar to Java's annotations, aren't you familiar with 
those either? 
(http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 27 2007
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 9/27/07, Bruno Medeiros <brunodomedeiros+spam com.gmail> wrote:

 It's a concept similar to Java's annotations, aren't you familiar with
 those either?


Nope. I have always found C and C++ (and now D) to be perfectly
adequate for every need I've ever had.

So tell me, what are these things _for_? What's the _point_ of them?
What do they do, and why would adding them to D be a good idea.

What will it enable me to do that I can't already do in C, C++ or D?
Sep 27 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Janice Caron wrote:

 On 9/27/07, Bruno Medeiros <brunodomedeiros+spam com.gmail> wrote:

 It's a concept similar to Java's annotations, aren't you familiar with
 those either?


 
 Nope. I have always found C and C++ (and now D) to be perfectly
 adequate for every need I've ever had.
 
 So tell me, what are these things _for_? What's the _point_ of them?
 What do they do, and why would adding them to D be a good idea.
 
 What will it enable me to do that I can't already do in C, C++ or D?


Look, ignore the syntax; it's not important.  Pretend I used  s or $s or
whatever makes you comfortable.

The point is, it's a system for annotating declarations.  Like how you
scribble in the margins of a book next to a particularly inane
paragraph: "this guy is nuts!"  You know... *metadata*.

And I would have thought the examples I gave before were a pretty good
example of why they're useful.  Look at the first class; I've used them
to annote fields with information on how they should be serialised.  In
the second one I've used them to indicate how an object might be bound
to a UI.

Ary has an even better example: specifying how to bind an object to a
database table.  That's like what ActiveRecord (the real magic behind
Ruby on Rails) does.  It'd practically give us half of D on Rails.  :P

The point is to give programmers a way of adding extra information about
a declaration that you wouldn't normally be able to convey.

Granted, you *could* do this in D right now; in much the same way you
can do OO programming in assembler.  You could probably fake it with
variadic templates and structs, etc., but it'd be ugly as heck.

	-- Daniel
Sep 27 2007
next sibling parent "David Wilson" <dw botanicus.net> writes:
On 27/09/2007, Daniel Keep <daniel.keep.lists gmail.com> wrote:


 The point is, it's a system for annotating declarations.


Modules, fields, properties, methods, structs, classes, parameters and
return types to be precise (IIRC).


 And I would have thought the examples I gave before were a pretty good
 example of why they're useful.


Source code can only ever show the *how* ;).


.NET attributes are a fairly awesome concept, but I'm not sure if they
fit in with the simplicity of D. Another thing is, .NET has a rather
powerful and well designed API for doing introspection, whereas D's
capabilities are quite simplistic.

I think it's a nice idea, and indeed I was looking for something
similar in D not a week ago. ;)  But I wouldn't miss the complexity if
it were never added. Attributes are a luxurious way of doing things
rather than a necessity.


David.



  Look at the first class; I've used them
 to annote fields with information on how they should be serialised.  In
 the second one I've used them to indicate how an object might be bound
 to a UI.

 Ary has an even better example: specifying how to bind an object to a
 database table.  That's like what ActiveRecord (the real magic behind
 Ruby on Rails) does.  It'd practically give us half of D on Rails.  :P

 The point is to give programmers a way of adding extra information about
 a declaration that you wouldn't normally be able to convey.

 Granted, you *could* do this in D right now; in much the same way you
 can do OO programming in assembler.  You could probably fake it with
 variadic templates and structs, etc., but it'd be ugly as heck.

        -- Daniel
Sep 27 2007
prev sibling next sibling parent reply Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Daniel Keep wrote:


 The point is to give programmers a way of adding extra information about
 a declaration that you wouldn't normally be able to convey.
 
 Granted, you *could* do this in D right now; in much the same way you
 can do OO programming in assembler.  You could probably fake it with
 variadic templates and structs, etc., but it'd be ugly as heck.


Makes me think that maybe e.g. 'unittest', 'deprecated' and pragma should
have been annotations instead of keywords. Annotations feel a much more
extensible facility than a fixed set of keywords. I'm not really sure what

tools) could really have a use for annotations in general. The language
should not dictate what 3rd party tools can and cannot do.
Sep 27 2007
next sibling parent Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Jari-Matti Mäkelä wrote:


 Daniel Keep wrote:
 

 The point is to give programmers a way of adding extra information about
 a declaration that you wouldn't normally be able to convey.
 
 Granted, you *could* do this in D right now; in much the same way you
 can do OO programming in assembler.  You could probably fake it with
 variadic templates and structs, etc., but it'd be ugly as heck.


 
 Makes me think that maybe e.g. 'unittest', 'deprecated' and pragma should
 have been annotations instead of keywords. Annotations feel a much more
 extensible facility than a fixed set of keywords. I'm not really sure what

 tools) could really have a use for annotations in general. The language
 should not dictate what 3rd party tools can and cannot do.


I guess this is yet another good example of the principle that the simpler
the core language, the more it actually allows one to do.
Sep 27 2007
prev sibling next sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Jari-Matti Mäkelä wrote:

 Daniel Keep wrote:
 

 The point is to give programmers a way of adding extra information about
 a declaration that you wouldn't normally be able to convey.

 Granted, you *could* do this in D right now; in much the same way you
 can do OO programming in assembler.  You could probably fake it with
 variadic templates and structs, etc., but it'd be ugly as heck.


 
 Makes me think that maybe e.g. 'unittest', 'deprecated' and pragma should
 have been annotations instead of keywords. Annotations feel a much more
 extensible facility than a fixed set of keywords. I'm not really sure what

 tools) could really have a use for annotations in general. The language
 should not dictate what 3rd party tools can and cannot do.


Indeed. It seems to follow a general pattern that software meant to be 
used by a large population may benefit a lot from extensibility (even if 
the core purpose of the program does not require extensibility). We have 
examples in desktop applications such as Mozilla, Firefox, Winamp; in 
development tools such as Eclipse; and in games this principle also 
seems to apply (the ability to mod a game greatly increases its value, 
there are even games born out of mods, such as Counter-Strike)

After Java annotations came out, third party tools quickly adopted it to 
various uses, one of them being to define Object-Relational DB mappings, 

OR mapping (like I have in the past, with Apache OJB), you know how 
inane and annoying that is. I've recently taken a look at OR mapping 
using Java annotations and it's way, *way* better. Safer, less brittle, 
less verbose and more readable. This kinda of stuff can open whole new 
segments in the target population of a language.

But in any case, we'd need runtime reflection first, to have something 
like this. Compile-time annotations only would be of limited use (I think).

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 27 2007
prev sibling parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Jari-Matti Mäkelä wrote:

 Makes me think that maybe e.g. 'unittest', 'deprecated' and pragma should
 have been annotations instead of keywords. Annotations feel a much more
 extensible facility than a fixed set of keywords. I'm not really sure what


That's exactly how it's done in .NET:

ObsoleteAttribute:
http://msdn2.microsoft.com/en-us/library/system.obsoleteattribute.aspx

TestFixtureAttribute and TestAttribute in NUnit:
http://nunit.org/index.php?p=attributes&r=2.4.3




 tools) could really have a use for annotations in general. The language
 should not dictate what 3rd party tools can and cannot do.


They're pretty much the same thing.


-- 
Julio César Carrascal Urquijo
http://jcesar.totumo.net/
Sep 27 2007
next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
Thank you Daniel, for that wonderful explanation. I've got it now. It
all makes sense.

Seems to me that this is a good idea, because, like templates, it
allows things to be done in libraries and user code which would
otherwise have to be done in the language. It makes the langage
/simpler/, not more complicated, but at the same time it lets you
express more. That's gotta be a win-win all round.

It would mean that we could deprecate "deprecated" (ironically), and
replace it with an annotation. Ditto pragmas.

xxxxx said it wouldn't be much use without runtime reflection. I
disagree. Compile-time annotations would still be useful. As noted
above, compile-time annotations would allow us to get rid of
"deprecated" (and also "unittest" and "pragma"). How can getting rid
of keywords not be a good thing? It would also allow for some pretty
cunning templates, assuming that templates could specialise on the
presence (or absence) of an annotation. Runtime reflection can come
later (if that's that way D goes).

However, I would like to say this, before the ink dries on the paper -

that (in my opinion) there are things much worse than keyword bloat,
and among those worse things I would include operator bloat and
punctuation bloat. (Operator bloat is just a special case of
punctuation bloat). You can argue that too many keywords pollutes the
namespace, but to give too many different meanings to too many
combinations of punctuation marks is way, way worse. I don't want to
see  *%!? and the like in source code, and have to learn what it
means. Walter got it absolutely right when he introduced the cast()
syntax - it's /totally/ readable. So, here, I believe, is a
circumstance where a keyword is desirable, and preferable to any
combination of punctuation marks. Compare:

     big  fat int f(int n); // Java style



    metadata(big,fat)
    int f(int n); // One possible alternative

    keywords(big,fat)
    int f(int n); // Another possible alternative

    pragma(big,fat)
    int f(int n); // A third alternative

My third suggestion re-uses the already reserved word "pragma", so no
new reserved words would have to be introduced, so even keyword bloat
is avoided.
Sep 28 2007
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 9/28/07, Janice Caron <caron800 googlemail.com> wrote:

 xxxxx said it wouldn't be much use without runtime reflection.


Yikes! Apologies. Read that as Bruno.
Sep 28 2007
prev sibling parent janderson <askme me.com> writes:
Daniel Keep wrote:

 
 Janice Caron wrote:

 On 9/27/07, Bruno Medeiros <brunodomedeiros+spam com.gmail> wrote:

 It's a concept similar to Java's annotations, aren't you familiar with
 those either?


 Nope. I have always found C and C++ (and now D) to be perfectly
 adequate for every need I've ever had.

 So tell me, what are these things _for_? What's the _point_ of them?
 What do they do, and why would adding them to D be a good idea.

 What will it enable me to do that I can't already do in C, C++ or D?


 
 Look, ignore the syntax; it's not important.  Pretend I used  s or $s or
 whatever makes you comfortable.
 
 The point is, it's a system for annotating declarations.  Like how you
 scribble in the margins of a book next to a particularly inane
 paragraph: "this guy is nuts!"  You know... *metadata*.
 
 And I would have thought the examples I gave before were a pretty good
 example of why they're useful.  Look at the first class; I've used them
 to annote fields with information on how they should be serialised.  In
 the second one I've used them to indicate how an object might be bound
 to a UI.
 
 Ary has an even better example: specifying how to bind an object to a
 database table.  That's like what ActiveRecord (the real magic behind
 Ruby on Rails) does.  It'd practically give us half of D on Rails.  :P
 
 The point is to give programmers a way of adding extra information about
 a declaration that you wouldn't normally be able to convey.
 
 Granted, you *could* do this in D right now; in much the same way you
 can do OO programming in assembler.  You could probably fake it with
 variadic templates and structs, etc., but it'd be ugly as heck.
 
 	-- Daniel


I agree, whatever the solution is (even if its just in the standard 
library) it needs to be standard otherwise it defeats the purpose of 
being able to simply import 3rd-party libraries that will work with your 
markup.

-Joel
Sep 29 2007
prev sibling parent Ary Manzana <ary esperanto.org.ar> writes:
They allow you to add information about classes, methods, etc, directly 
in their source code. Then you can access that information either at 
compile time or runtime. So for example you can have a class that 
represents an object that maps to a database:

[Table("Person")]
class Person {

   [PrimaryKey("Id")]
   int id;

   [Field("Name")]
   char[] name;

}

Then you can have a class that knows how to save objects into a database 
by just querying those attributes. This is very comfortable since you 
have the specification of how to map a class to a database right in the 
class' definition, instead of in another file.

I guess they are a generalization of attributes like "public", "static", 
"const", etc (you could have [Public], but it's more verbose).

An example of a compile-time attribute is [SuppressWarning(id)] (in 
Java, at least), that instructs the compiler to not generate some 
warnings for a certain class, method, etc.

Janice Caron wrote:

 This is obviously some strange usage of the word "explain" that I
 wasn't previously aware of :-(
 
 Any chance anyone could explain what that means? Square brackets mean
 array access to me, so just sticking function calls in square brackets
 where it would be a syntax error to do so does not really constitute
 an explanation in my book.
Sep 27 2007
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2007-09-26 15:33:25 -0400, Sclytrack <sclytrack pi.be> said:





I'm all for it.

If done properly, this could allow me to simplify drastically the 
D/Objective-C bridge which is currently mimicking that with templates. 
It would make the syntax cleaner and could potentially make compilation 
much faster too.

In the bridge, I'm currently mimicking this with a mixin, for instance:

	class MyClass {
	
		void value(int v) { ... }
		mixin ObjcBindMethod!(value, void, "setValue:");
		
	}

This currently works by adding to the class a member struct I can later 
access using tupleof (D version 1 here). That struct only has static 
members so that it does not take up any space in object instance. These 
static members include the method definition for the Objective-C 
runtime with a pointer to a generated forwarder function.

Each method binding mixin has to repeat the function name, the return 
type and the type for all arguments, leaving only the Objective-C 
selector unrepeated. That's innefficient and somewhat error-prone.

With proper reflective attributes, things could be much cleaner.

Binding to Objective-C isn't much different from binding to a GUI, so 
surely this can benefit other senarios too.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Sep 27 2007