The Power of Programming With Attributes

Wednesday, May 14, 2008

Nothing can compare to the Real Power of programming with attributes. Why, just one pair of square brackets and woosh – my object can be serialize to XML. Woosh – my object can persist to a database table. Woosh – there goes my object over the wire in a digitally signed SOAP payload. One day I expect to see a new item template in Visual Studio – the "Add New All Powerful Attributed Class" template: *

public class Person
Description("The person's name")]        
public string Name { get; set; }


Which begs the question – could there ever be a way to separate attributes from the class definition?**

* Put down the flamethrower and step away - I'm kidding.

**This part was a serious question.

Kevin Dente Wednesday, May 14, 2008
Put them in a separate XML config file?

I kid, I kid.

Seriously, though, attributes often seem like a violation of SOC.
kokos Wednesday, May 14, 2008
One simple way you can use today is partial classes: put the related attributes that contains only the type name and the actual content elsewhere. You can mix these however you want.

Or you can make a request for a new attribute in the next version of the platform:
[assembly: ApplyAttribute(Type=YourType,Attribute=YourAttribute)].

Or go crazy and put the attributes in xml and... go crazy :D
kokos Wednesday, May 14, 2008
Just wanted to add that the ApplyAttribute I mentioned should be understood by the compiler and put in the right place at compile time, so that GetCustomAttributes and related methods still work.
Laurent Wednesday, May 14, 2008
What about using .NET 3.5 partial methods ?
Francis Norton Wednesday, May 14, 2008
The nearest I've got to this experience so far was the realisation that I could add class attributes and even inheritance via partial classes.

What would you do with this feature? Would it be able to work across assemblies? Could you add attributes to other people's libraries?

AOP would be cool, and I can see something like Spec#.

And I can see lots of wizardry being required to stitch it all together again, to give a re-unified view in VS or Reflector.
Rob Paterson Wednesday, May 14, 2008
Wouldn't a list of attributes separate from the source code just be an XML config file? Which is what attributes is trying to avoid I would imagine. I'm guessing a bit as I'm a Java programmer interpreting attributes as an 'annotation'.
Lars Haupt-Hansen Wednesday, May 14, 2008
Suppose you make an attribute [Template(name="PowerfulClass")] and then stored the Attribute templates in an XML document somewhere:

<!-- something notation to include namespaces -->
<Template name="PowerfulTemplate">
<DefaultProperty name="Name"/>

<!-- class specific goes here -->
<Class class="My.Demo.Foo">

Templates could be used for classes with the same behaviour and Class tags could be used for individual tweaking.

Of course you'd have to plugin at runtime so querying on attributes will read from the xml file instead from the assemblies directly. Not sure if that is possible though.
scott Wednesday, May 14, 2008
@Kevin: SoC violations are easy. Where attributes drive me nuts are in designer components. It's though to look at the source code when there are so many decorations on the class.

@kokos, @Laurent: I've thought about partial classes, partial methods, but it feels wrong. I don't like to use partials myself. I feel they should only be present when a code-generation tool is used.

@Lars: It hurts my eyes :) But, that was something along the lines of what I was thinking.

Scott Seely Wednesday, May 14, 2008
With KnownTypeAttribute (System.Runtime.Serialization/WCF), you can declare aspects outside of code since DataContract recognizes that you may not own the code that you need to serialize.

Ditto for exposing a COM+ service over WCF.

See the following:

Details on COM+ and how to integrate with WCF via the SvcConfigEditor tool:

Oran Wednesday, May 14, 2008
I wonder if you can use PostSharp and/or Laos to post-compile the attributes in after the fact based on external config.
Jared Parsons Wednesday, May 14, 2008
The best way I can think of is not actually removing them from the class but instead adding them to a partial class. That would take away them being directly on the class you are editing but won't actually remove them from the class.

The other downside is this will only work for class attributes and won't help for methods/properties/fields/etc ...
Ben Scheirman Friday, May 30, 2008
This solution would likely be full of gotchas, but they could extend the partial syntax to work for class members as well.

public partial class Foo
public string GetStuff();

public string Yuck

this would all be syntactic sugar over our current CLR.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!