Joel is soliciting suggestions for new framework features on [ausdotnet] at the moment, so its time for me to get something off my chest. While attributes in .NET are cool I think they could be so much more. As it currently stands attributes are a way of annotating classes, methods, fields etc with extra meta-data and not much more. To actually DO something with an attribute you need to implement some kind of processing pipeline that reads the attributes (via reflection) an then takes some action. The [Serializable]/[XmlElement]/[XmlAttribute] attributes are read by their respective serialization “pipelines”, [WebMethod] is read and used by the ASP.NET processing pipeline etc. This is great for 3rd party “pipeline” builders (NUnit uses attributes to decorate methods and classes to mark them for unit testing) and the respective framework teams, but kinda limited for those of us who need to play in the pipelines of others. The only example where attributes can actually take some action is when you apply a ProxyAttribute to a ContextboundObject, in which case the attribute can intercept calls to the method…hey, doesn’t that sound cool? The problem is of course that we may not want or be able to change our bass class to contextboundobject just to get this cool interception feature. This brings me to suggested attribute enhancement #1
1. Attributes on methods should be able to perform interception without your object having to inherit from any one particular bass class.
Effectively what I’m asking for (or what I think I’m asking for) is the CLR to throw up contexts around an object without it having to explicitly inherit from ContextBoundObject. I don’t mind having to be explicit about this - maybe a [ContextBound] attribute? It’s either that or give me multiple-inheritance (ok…I’ll wait for you to stop laughing).
My next suggestion for attributes is that
2. Attributes which are applied to a class or member variable should get passed that thing, when the instance of the thing is constructed.
This (to my mind anyway) would render our recent discussion of extender providers fairly moot as it would let you write code like this:
[SecureControl(RequiresRole=”Admin”)]
System.Windows.Forms.Button myButton;
or this
[SaveToViewState]
int myCounter;
My third suggestion (and maybe this just shows I don’t get the “they’re like a tattoo - static and permanent” nature of attributes) is
3. Attributes should be able to be dynamically added and removed from things they’re applied to.
I don’t have any strong use-cases for this one, but I get the feeling the dynamic language folks might.
Feel free to flip the bozo bit accordingly.
Disclaimer: I haven’t really checked to see if/how attributes may have changed in framework 2.0, but I haven’t heard of any significant enhancements in this area. If you can do any of these things NOW in 1.x or 2.0 let me know as I would love to use them for a few different things. No considerations of how this all might be implemented, what the implications for performance, security or ending hatred and intolerance were made during the making of this weblog post. Bits may have shifted during transit.