Ouch! There is a Hook in My C#

I would like to draw your attention to an interesting aspect of C# language design.

As an extension to the J++ design practice, C# has a syntactic construct, called Attributes, which let you drop hooks to Windows API or modify the runtime semantics, like threading synchronization behavior. The C# has legalized the hooking practice by calling them Attributes, and including them in ECMA C# specification. See document number ECMA/TC39/TG2/2000/3, chapter 17.

All the .NET targeted languages, including C#, generate MSIL (Microsoft Intermediate Language), which heavily uses the .NET API (or in Microsoft's lexicon, .NET Framework). Thus, Hejlsberg probably could not resist the temptation to keep C# open ended by providing a trap door to access the runtime, without having to add additional syntax. Attributes have been put to varied use ranging from calling DLL (JDirect legacy) to switching between managed and unmanaged codes, and even to modify the synchronization semantics.

To highlight this point, I will use the Threading Synchronization design and implementation of C#. The .NET platform implements threading and synchronization in the CLR (Common Language Runtime) through the set of classes implemented in the System.Threading namespace hierarchy.

Since the .NET Framework API is exposed to C# programmers, they have a choice to implement inter thread synchronization by directly using the System.Threading API classes (like System.Threading.Monitor and System.Threading.Mutex classes), or using the lock keyword of C#. You could also use the Synchronization Context Attribute, [Synchronization()], just above the class declaration, to make all methods of the class synchronized! I recommend, Anders Hejlsberg, to apply the Occam's razor on this portion of C# language design, because, I believe that the design simplicity, should demonstrate the power of the idea behind it.

Internally, the C# compiler uses System.Threading.Monitor class Monitor.Enter, and Monitor.Exit methods to implement the C# lock and using semantics.

Attributes are little more than glorified flagging mechanism, allowing for ad hoc hooks to the runtime semantics; supported by .NET Framework API.

Attribute concept in general provides a hook to the implementers of the runtime, to extend the semantics of the language usage. This may be useful if only Microsoft dictates the extendibility, however, it will create havoc if third party CLR become available.

The .NET Framework is a set of API which expose the CLR (Common Language Runtime) features in an Object oriented manner. This has a far-reaching design and architectural implication.

On one hand this is useful for interoperating between languages. All language compilers have to do is to map the syntax of a language to IL (Intermediate Language), which aided by CLR define the language semantics. On the other hand, the syntax of a language, such as C# becomes tied-up radically with the API.

Thus the basic tenet on which the language 'C' (the mother of C++, and granny of Java and C#) is violated. 'C' had a design philosophy that lib (or API) is independent of the syntax and semantics of the language, while the Lib. Provide pragmatics. This creates space for the programmers to interpolate frameworks. For example, if you were a C++ programmer you may want to have a choice between MFC (Microsoft Foundation Classes) and OWL (Object Windows Lib.). Thus the original K&R 'C' did not define stdlib as part of its language definition.

But, C# design is tied down heavily to the .NET Framework API.

For example, the keyword delegate, in C# is a syntactic hook to System.Delegate hierarchy. I think, Anders Hejlsberg fell again into the classic language design trap, of not applying Occam's razor.

Occam's razor is a powerful concept of design iteration for simplifying designs by cutting out duplicated features and complexities, this concept was expertly applied by K&R while designing the 'C' language.

I hope that this practice of "Attributing" does not percolate into the designs of future languages. I am sure that these attribute constructs will have James Gosling and Bjarne Stroustrup fuming! (Just kidding).