Amazon.com Widgets

The SLAR on System.AttributeUsageAttribute

Boy, it has been a while sense I did one of these… but, never the less, continuing in the series on sharing some of the information in the .NET Framework Standard Library Annotated Reference Vol 1 here are some of the annotations on the

System.AttributeUsageAttribute class. 

 

BTW, if you have comments (good or bad) on the book, I’d love to hear them.  In addition I encourage you to post them to Amazon where other developers can benefit from them.

 

BA Notice that this custom attribute is sealed. In general I am not a big fan of randomly

sealing classes to prevent extensibility. (I prefer non-virtual methods for that

purpose.) However, for custom attributes it is a good practice. In the .NET Framework,

the reflection code path that looks up custom attributes from members is

slightly faster if it does not have to consider subclasses of the target attribute.

 

BG In general, sealing a class or making members non-virtual (when appropriate)

can help a JIT to inline methods. Inlining has always been a powerful optimization, but

virtual methods can prevent inlining. Sealing members or leaving them non-virtual also

allows you more flexibility in changing your class’s implementation in the future, by

limiting users’ points of customization. Non-virtual members definitely have an appropriate

place both as a design point and as an implementation detail for better

Performance.

Users defining their own custom attributes should specify the AttributeTarget-

Attribute at all times. Like this:

[AttributeUsage (AttributeTargets.Methods |

AttributeTargets.Properites,

AllowMultiple=false)]

public class MyNewAttribute : Attribute

{

public MyNewAttribute () {}

}

We begrudgingly added the AttributeTargetAttribute to the Attribute class

so that people subclassing Attribute didn’t need to understand another custom

attribute when creating their own custom attribute. However, this allows people

using that new attribute to put the attribute in potentially surprising places. If you

define an attribute to function as a marker on an assembly, your program might not

work as expected if you happen to find the custom attribute applied to the return

value of a method. Class library authors really need to understand and use this

attribute.

 

Published 27 August 04 08:27 by BradA
Filed under:

Comments

# Matthew W. Jackson said on August 27, 2004 1:16 PM:
My favorite part is how AttributeTargetAttribute is applied to AttributeTargetAttribute. I've actually come across several cases where an attribte could be applied to itself (such as Mono's TODOAttribute). I guess that helps show how attributes aren't instanced until they are reflected.

Just imagine if you guys had applied ConditionalAttribute to the ConditionalAttribute in Whidbey.

Anyway, was there any thought put in to having the compiler warn you when you declare an attribute class without an AttributeTargetAttribute defined?

Are there any cases where you might not want to explicitly state the targets of an attribute?
# Keith Hill said on August 27, 2004 1:16 PM:
While we are on the subject of attributes ... :-) I was playing around with the new
System.Runtime.Serialization.OnDeserializedAttribute. The docs don't specify
what the signature should be for the target method just yet so I put in:

[OnDeserialized]
private void OnDeserialized() { ... }

That compiles just fine! That is scary! Much of the benefit of a strongly
typed platform like .NET is compile-time type safety. I didn't find out that
the method should take a StreamingContext parameter until I got a runtime
error. What if this method was only called in extreme corner cases (like a
rarely serialized object). I might not find out until my code is shipping!
Boo!

Proposed Solution:
Create a TargetSignature constraint attribute that can be placed on
Attribute classes like OnDeserialized that specifies what the target
signature of the target method has to be. One way to do this would be to
define a delegate like so:

public delegate void SerializationCallback(StreamingContext);

and then I would use it on the attribute like so:

[AttributeUsage(AttributeTargets.Method),
TargetSignature(typeof(SerializationCallback))]
public class OnDeserializedAttribute : Attribute { ... }
# Matthew W. Jackson said on August 27, 2004 5:10 PM:
I second that suggestion.

The same thing could then be added to NUnit (and any other unit testing framework) to make sure you don't put a TestAttribute on anything other than void(void).
# Matthew W. Jackson said on August 28, 2004 12:56 AM:
I had another thought. An attribute such as the one suggested could also be used to restrict class-targeted attributes. Then certain attributes which can only apply to types inheriting from a certain type could be restricted. For example, AttributeUsage could be marked to only apply to classes deriving from Attribute.

This could possibly be the same attribute as suggested by Keith (with perhaps a different name), or a new attribute.

However, I don't know that a new attribte would be needed at all. A new "Type" property called TargetType could be added to AttributeTargetAttribute. I don't think that this would break compatability.

So, in Keith's example, the attribute would be:

[AttributeUsage(AttributeTargets.Method, TargetType=typeof(SerializationCallback))]

And an attribute that could only be applied to an Attribute class would look like:

[AttributeUsage(AttributeTargets.Class, TargetType=typeof(Attribute))]

Or maybe this could be two properties in case both a class type and method signature needed to be specified.

This is just something to think about. There are several similar things that could be done, such as restricting attributes on properties or fields to certain types of fields (I could see this possibly being used for P/Invoke attributes), although the Method Signature Restriction would be the most important, followed by Base Class Restriction.
# ApeDant said on August 30, 2004 7:25 AM:
s/Properites/Properties/
# paulb said on September 1, 2004 3:47 PM:
Speaking of the SLAR, when will the remaining parts be published? I'm really looking forward to the XML classes.
# Brad Abrams [MSFT] said on September 3, 2004 8:33 AM:
Soon.... we are very close to having a draft that can be reviewed... Just last week I reviewed the final set of annotations and they are even better than vol1, especially in the Xml classes.
New Comments to this post are disabled

Search

Go

This Blog

本博客中文版 (View in Chinese)



These postings are provided "AS IS" with no warranties, and confer no rights.

Syndication

Page view tracker