Attribute usage | Tech Off

Maddus Mattus
it really does!

Recently had a debate with a collegue about when to use attributes.
I was against the use because (in our scenario):

It complicated the code
It could be solved in a different way more easily
It relied on reflection (security? performance?)
I believe it should be used when you need meta data to communicate between two classes who are unknown to each other, wich was not the case

Can anybody point me to some guidelines or proven practices? Cause I've been searching the net and couldnt come up with any.

stevo_
Casablanca != Manchester

The reason for attributes are really to provide static extensibility.. theres nothing else that really provides static extensibility..

I can't really see security issues as such.. perf- sure it may be slower, but you need to see if that is going to be a problem.. (is 1% perf worth getting to make your system work in a different, possibly worse way?)..

Plus, attributes aren't just for types, they effect other members like properties, fields etc.. of which cannot be 'hacked' with say... interfaces..

By hacks, I mean using instance methods to give type-constant responses.. which isn't so much a hack, but not exactly 'pure'..

Maddus Mattus
it really does!

Thanks for the input.

Still leaves me with the question when to use it and more importantly, when not to use it.

I've taken a look under the bonnet of the .net framework. They tend to use attributes for technical purposes. But the MSDN speaks of providing functional meta data, such as a currency for an amount:

[Currency("Euro")]
public double Salary{ get; set; }

I personally do not feel for these types of attributes, but I cannot put my finger on it.

My motto is:

Keep it simple, stupid!

unless there is an urgent reason to use em, use em. Otherwise leavce em out. What do you guys think?

TommyCarlier
Trust me, I'm from the Internets

Attributes can be a security risk: when you load an assembly and a type in that assembly, the attributes are instantiated and their constructor is executed. So if you use some kind of plug-in system that scans assemblies for plug-ins, code is executed that you might not want to be executed. That's why you should use Assembly.ReflectionOnlyLoad (new in .NET 2.0) to read metadata from assemblies you don't trust.

TommyCarlier
Trust me, I'm from the Internets

The example of the Currency-attribute is pretty lame. When you're building an application that needs to express the currency of a salary, that's not metadata but regular data. It would be better implemented as a property instead of an attribute. Attributes are useful for some scenarios, but should not be used if it's not necessary.

Sven Groot
You can't have everything; after all, where would you put it?

On the other hand if you're writing some sort of designer or other GUI tool that's going to be reflecting the properties anyway, then expressing the unit of a property using an attribute makes perfect sense (assuming that information is important to the tool). It's pretty much how a lot of the stuff the WinForms designer does works.

Maddus Mattus
it really does!

So basically only when it's added value and when there is no other solution.

vesuvius
Everyone has talent at twenty-five. The difficulty is to have it at fifty.

Think the currency example is overkill, and tend to use attibutes soley for user controls/components, and serialization, but this is client development. I know in ASP.NET that users controls are different so different considerations must apply.

If you have a similar/identical scenario in the .NET framework, I'd just debug it, and see how MSFT handle the similar/identical scenario.

stevo_
Casablanca != Manchester

Maddus Mattus wrote:

So basically only when it's added value and when there is no other solution.

I wouldn't say that so much, that makes it sound like the attributes system was a disaster..

In your example, you use the attributes to extend the properties of the data, where as really this just makes it harder for accessors to get full context of the data they work with..

Attributes on members really should describe something thats abstract to the type of data that member is, serialization for example: you wouldn't want every member to have to state its serialization intent, so instead- you use attributes as 'stand off' data..

The argument I guess you could say more is, should the functionality this attribute gives, be generically part of all target members, or should it be stood off from the member?

Extending to this, you attribute example describes more the data of the property, vs describing the property itself.. where as the attributes should describe the member (not to say that the attribute shouldn't effect how the members data could be used).

vesuvius
Everyone has talent at twenty-five. The difficulty is to have it at fifty.

stevo_ wrote:

The argument I guess you could say more is, should the functionality this attribute gives, be generically part of all target members, or should it be stood off from the member?

Extending to this, you attribute example describes more the data of the property, vs describing the property itself.. where as the attributes should describe the member (not to say that the attribute shouldn't effect how the members data could be used).

Both must exist and one must know when one is appropriate. In serialization you can decorate the class as [serializable], this would be a generic implementation.

In WCF each data contract must be "stood off" so a generic implementation is not suitable here.

In a nutshell, decorate as and when appropriate.

Maddus Mattus
it really does!

Thanks for thou input!

littleguru
allein, allein,... allein, allein!

I use attributes whenever the class/method/property/field should have additional functionality that's hard to implement otherwise. For example if you do a reasoning over the mentioned constructs and you need additional information to complete the process, eg. a serializer or similar.

Externsibility via designers is also a nice example.

But the currency thing is a complete overkill; especially since when you want to change the currency you need to recompile the whole application.

The speed argument is none in my eyes. You can always inject some optimized or cache them in a way to walk around the slow reflection API... - something like the DLR already does.

Seucrity might be a reason not to use them... but that really depends on who defined the attributes and how you load the assembly.