We Keep Coding

Restrict Enum parameter to certain Enum types (at compile-time)

I created a static void Method (Enum myEnum), but I'd like to feed it only certain Enum types, or face my mistake at compile-time. As I'm experimenting a lot with my code (using gameplay mechanics as shader variants), I need to change the accepted types on a whim, with the least possible maintenance of the Method class.
Basically, I'm struggling to do with enums what I could have very easily done working with classes (create a shared base class to use as parameter type). The first that came to mind were attributes:
Can a custom attribute affect compilation in any way? I'd be surprised if it could.
Can I mimic class inheritance in any way for Enum types, albeit just to create some kind of category to restrict method parameters?
This is my impossible dream code:
[AttributeUsage(AttributeTargets.Enum)]
public class ShaderVariant : System.Attribute { }
void Method (T myEnum) where T : [ShaderVariant]Enum { }
My current options are:
Create the aforementioned attribute to tag the selected Enum declarations, and react to it during runtime (throw an ArgumentException if myEnum.GetType() doesn't have the attribute). This approach silently allows me to mess up while coding, but only having to add/remove an attribute to any Enum I want is my dream-workflow.
Declare a ludicrous amount of wrapper overloads for each type and forever maintain the Method class, doomed to commit the same file over and over again for every slight change made to the project. But works at compile-time.
This question is about how C# works. I know it's easier to create the wrapper overloads, but it feels wrong subjugating the handler method to support what essentially is a parameter property.

Enums are simply short names for constant numbers.
If members of an Enum are different, as some has to be acceptable in Compile time to a method and some not.. then maybe you need two Enums. One will have members acceptable to a method an one having all possible options.
Enums are very simple structures without inheritance. If you see feel like you need inheritance, then you probably should not use Enum and use classes.

What's with using C# attributes with the 'Attribute' suffix?

I'm looking at some C# code that applies several LINQ to SQL attributes with the Attribute suffix, e.g. ColumnAttribute, instead of the plain Column that I am used to using. Is there any reason but verbosity to do this?

There is no semantic difference. Probably whoever wrote the code just preferred that notation.
It's also possible that the code was automatically generated using a tool. Code generation tools usually don't bother to strip the Attribute bit from the attribute's type name.

Most attributes end with the word Attribute, including ColumnAttribute, CLSCompliantAttribute, and SerializableAttribute. The compiler allows the last word Attribute to be omitted. It's the programmer's choice whether to add Attribute to such names or not.
The Attribute suffix, however, is merely a convention: it is perfectly valid, albeit unusual, to define an attribute, for example, as follows:
[AttributeUsage(AttributeTargets.All)]
public class Foo : Attribute {
}
just as it is to define an exception named Throwable, for example.

The attribute is called ColumnAttribute. The compiler just provides syntactic-sugar to allow you to specify them without the Attribute suffix.
There's no practical difference.

No, it's just a style decision. However, if what you're looking at is code generated using CodeDOM the presence of the suffix is expected since C# code generator will keep the full ___Attribute type name when adding an attribute.

They're syntactically the same. AFAIK there's no reason to do this unless the person in question wasn't familiar with the fact that syntax sugar in C# adds the 'Attribute' suffix automatically when adding an attribute via square brackets.

Column is simply the nickname of ColumnAttribute, and syntactically identical in functionality, and allowed by the compiler in either form.
Some people prefer to use the full name, out of habit of following the Framework Naming Guidelines, which encourage adding Attribute to custom attribute classes, or I to interface types.

If you look at the Philips Healthcare - C# Coding Standard, rule 3#122, you can see they actually want coders to add the suffix "Attribute" to attributes.
http://www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf
The code may be generated but the author(s) of the code generator are probably trying to create code that meets as many standards as possible.

Adding a property without touching the class? (not inheritance)

I got a requirement in my project to add another property to some class.
Now I want to avoid changing the class because I figured it shouldn't be aware that he has this property (this property only has significance in the context of this project).
The way I thought to accomplish this was (Please critic this because I wanna know if there are simpler ways of doing this)
Adding a new singleton class that has a mapping between objects of my class and the type of the property I wanted to add
adding in this class an extension method (extension property?) to access the mapping and fetch the property.
Is there a simpler alternative?
Is this just unnecessary complexity? Maybe I should just add a new property to my class?
Thanks!

The design you've described is actually the one used by Microsoft to implement the DependencyProperty system and, in particular, Attached Properties, though in the greater context of a binding framework. That said, using a dictionary with 'attached' data is a very typical solution when you need to tag a class with additional context for a particular use, but don't want to modify the class.

Why do you say "not inheritance"? Surely the way to do this, if you don't want to alter the original class, would be to inherit from the original class and then add your property to the derived class?
BTW, there are only extension methods, not properties, so you can't do it via property.

I would suggest the DECORATOR pattern. I know you say you don't want to use inheritence, but sometimes it's cleaner to do so. The pattern only uses inheritance to define the interface.

An extension method makes sense and it's also relatively simple.
[visibility] [type] [methodName](this [class to extend] c, ... more args if necessary)
{
....
}

Adding a property doesn't break the class's interactions with existing clients, so that really seems the "simplest" approach.
More important, though, is the function of the new property. Is it logically part of the existing class? Change the class. If not, then an extension method might be preferable, but the problem then becomes the visibility of the extension method, and scope of its clients.
As always, complexity is the enemy. In this case, it sounds as though the singleton is a very complex solution, and the extension method is hit-and-miss, depending on scope and visilbity issues. Changing the class is simplest, and will probably make long-term maintenance much easier.
UPDATE: Note that extension methods are static, and that makes it pretty difficult for the extension method to hold data of any time, as a property would be exptected to do.
SECOND UPDATE: If you have access to the source for the class, consider making it a partial class, and put your new property in a separate file, but part of the same partial class. This keeps it separate from the main body of the class for maintenance purposes, and will work with most ORMs. However, there is a restriction that the partial class members have to be in a single assembly.

Define a Nullable values with their Properties(while the Property has significance only for this project)
your major problem is that you don't want to change the class itself because this requirement is ONLY for 1 project (build), i think you are considering SOLID priniciples, one of these principles is OCP (Open-Closed Principle), that is,
your Entity must be open for extension
but closed for modification

C# AttributeUsage for Specific Class

Is it possible to have something like AttributeUsage to restrict the use of an attribute to a specific class (not just AttributeTargets.Class - that would be any class)?

One way to accomplish this, if you have access to the specific class, is detailed by Marc Gravel here: http://marcgravell.blogspot.com/2009/06/restricting-attribute-usage.html. Basically you implement the attribute as a protected class of the specific type. Then it can only be used by that type.

No. There is nothing in the framework that would do this.
However, the code that uses the attribute in question could always check to make sure that the class's type is the specific class (or one of its subclasses).
Attributes, by themselves, do nothing - so this should have the same effect.

Make all data in the Attribute accessible only by a public static method which takes the class you want in question and checks to see if it has the given attribute.

Meaning of text between square brackets

I have seen a lot of C# programs that use the [], for example [STAThread] and then the code follows. Another classic example is [DLLImport].
I know what STAThread means but my question is what is the significance of the square brackets, essentially what do they tell the compiler?

It's an attribute. Attributes are a form of metadata that you can attach to various code elements: classes, methods, assemblies etc.
Some attributes have special meaning to the C# compiler, for instance the [Serializable] probably tells the compiler to emit some code that can serialize an instance of the class (I say 'probably' since I do not know the inner workings of the C# compiler).
You can also create your own attributes (by inheriting System.Attribute). Using reflection you could then at run-time extract information from the attributes.
A simple example would be to create an attribute to specify what kind of input field to use in a HTML form when displaying an object's property.
Some links:
Book chapter on attributes
Attributes overview (MSDN)
https://stackoverflow.com/search?q=C%23+attributes
http://www.google.com/search?q=C%23+attributes

These are attributes.
Attributes have many uses - [Obsolete] marks a method as obsolete and the compiler will warn you. Others like [DebuggerNonUserCode] tell nothing to the compiler and are there to let the debugger know that the code in the marked method is auto-generated.
You can also create your own attributes and use them to mark any kind of metadata. For example, your Customer object might have an attribute [MarketingInformation("Customer is rich! Milk him good!")].

See here for info about attributes in .Net:
http://msdn.microsoft.com/en-us/library/5x6cd29c.aspx

They are attributes, that add meta data to whatever they are decorating.

Theses are called code attributes. Attributes are used to mark code with properties which are usually designed to specify behavior during execution. They are commonly used to mark methods, properties and parameters. During execution of your code something called "reflection" will be performed to examine the code. Reflection tells the compiler to observe and obey any instructions specified by you as the coder marking attributes against the code.
A good example would be the [Serializable] attribute. This attribute when marked above a class indicates to the compiler that it can be serialized for the purposes of persisting the class instance or for transmitting across a medium such as SOAP web services.
See the following article:
link text