"ga**********@gmail.com" <ga**********@gmail.com> wrote:
I am trying to understand Attribute usage. For example the class
SerializableAttribute is a class correct? So why when it is actually u
sed the "Attribute" portion of the name is dropped. The sam is true of
the AttributeUsageAttribute class and on and on. I don't get it.
There are two sides to look at: those who use attributes, and those who
write their own attributes.
When an attribute user places an attribute on an element, he or she
doesn't have to specify the "Attribute" part. This reduces typing on the
attribute user's part, and increases code clarity. Because every
attribute ends in "Attribute", the "Attribute" part is redundant.
For those who create attributes, they usually want something short and
snappy that has a high degree of relevance to what they're placing the
attribute on, but they don't necessarily want to require the attribute
users to qualify the namespace explicitly (since that would make
attribute usage quite wordy). This runs the risk of polluting the global
namespace with short identifiers. To prevent this, they usually follow
the convention that the attribute shall have the word "Attribute"
appended to it. (It isn't necessary for attributes to follow this
convention, but it is recommended.)
For example of what I mean by short and snappy, consider these
attributes defined as part of .NET:
---8<---
Flags
Obsolete
Serializable
Conditional
Obfuscation
OnSerializing
OnSerialized
OnDeserializing
OnDeserialized
Guid
In
Out
Optional
Discardable
Dependency
Security
Context
OneWay
Proxy
Soap
Synchronization
Url
--->8---
These attributes listed here are without their "Attribute" extension, to
illustrate how short and potentially ambiguous they could be without the
"Attribute" suffix convention. For example, somebody new to the
framework could easily mistake an "Url" type as representing the same
thing that "System.Uri" represents, and not recognize it as an attribute
type, and similarly for Guid. What would the newcomer make of a type
named "Proxy"? Wouldn't they think it actually represented a Proxy?
Another way of looking at these things is that attributes are usually
either nouns or adjectives that qualify whatever they are placed on. If
the attribute takes parameters in its constructor, it's typically a noun
which is logically becomes a kind of property of whatever it's attached
to. If the attribute doesn't take parameters, it often ends up being an
adjective.
The thing is, classes are usually given noun-based names too. But an
attribute noun that is logically a property of some reflection element
is something quite different from an actual class, which is meant to be
instantiated and manipulated.
Therefore, it makes sense to keep the two in separate namespaces. This
permits overloading of names where appropriate, but also prevents
conflicts. There usually isn't a risk of ambiguity, since the shortened
attribute names can only occur in a limited context, between '[]'.
The namespace separation comes about by the convention of adding
"Attribute". This creates a namespace separation without forcing
explicit namespace qualification to resolve ambiguities.
-- Barry
--
http://barrkel.blogspot.com/ 
