New CSharp Language features 3.0 and 4.0

This Page is Work in Progress

The content for this page is being written and not complete yet. Its content should not be relied on at the moment.

New features

C# 3.0

• see http://www.codeproject.com/KB/cs/csharp3.aspx
• see http://soumya.wordpress.com/2009/06/12/new-features-in-c-part-ii-c-3-0/

Implicitly Typed Local Variables (aka 'Local Variable Type Inference')

• At first glance this feature looks like it does what the 'dreaded' VARIANT Type of Visual Basic 6 does, where it results in late-bound Type Inference which can cause very difficult-to-spot errors at runtime.
• However, Implicitly Typed Local Variables result in early-bound strongly-typed code, which is way better as its VB 6 'colleague' as it can not cause those errors at run-time!
• Only works for local variables in a method (that is, not for Class Fields or Method Arguments).
• Implicitly Typed Local Variables are a 'compiler trick' (and as such work even with the .NET 2.0 Runtime - see [1]) .
• Usage
  • Use new var keyword for the declaration of such variables.
  • Should not be over-used as the source code is less explicit than when the Type it holds is stated explicitly.
  • Can be a time saver for declaration of long Types, esp. Generic Types; there it fine to be used and actually can result in easier-to-read code.
• Usage example in OpenPetra source code: none yet.
• Details: [2]

Auto-implemented Properties (aka 'Automatic Properties')

• Saves writing code for getters and setters of Properties that simple read and write a Classes' Field.
• Usage
  • Declare a Property like this: public int TestValue { get; set; }.
    • There is no need to declare a Field named 'TestValue' - this is done automatically by the compiler (hence the name 'auto-implemented Properties').
  • A neat feature, but it results in Class Fields that are named like the Property.
    • This goes against the naming convention for Class Fields in OpenPetra source code: Class Fields always need to start with the letter 'F' (for Field). Reasoning: to make it easier to distinct between local Variables and Class Fields in program code with a quick glance.
    • Alternative: IDEs can usually auto-generate source code for a Property declaration from a Field. All you have to do is to rename the Property to not start with the letter 'F' (for example, in SharpDevelop this automatic code generation is accomplished by choosing 'Create getter' or 'Create Property' from the context menu while the cursor is on a Field {it makes the 'F' start character of the Field's name lowercase, so correct it to uppercase to conform to another naming convention for OpenPetra source code).
• Auto-implemented Properties are a 'compiler trick' (and as such work even with the .NET 2.0 Runtime - see [3]).
• Usage example in OpenPetra source code: used already in the web server for the Conference back-end.
• Details: [4]

Object Initializers

• Saves writing code to set Properties of newly constructed Objects as this is done in one command at the point of creating the object, rather than in several commands.
• Object Initializers are a 'compiler trick' (and as such work even with the .NET 2.0 Runtime - see [5]).
• Usage: see Details below.
• Usage example in OpenPetra source code: used by ext.net which is used by the web server for conference back-end.
• Details: [6], [7]

Collection Initializers, Dictionary Initializers

• Similar to Object Initializers, but for the initialisation of values of Collections or Dictionaries.
• Collection/Dictionary Initializers are 'compiler tricks' (and as such work even with the .NET 2.0 Runtime - see [8]).
• Usage: see Details below.
• Details:
  • Collection Initializers: [9]
  • Dictionary Initializers: [10]

Anonymous Types

• An Anonymous Type is a compiler-generated, 'on-the-fly'-created Class.
  • They are described by the programmer through the combination of the features of Auto-implemented Properties and Object Initialisers.
  • The Classes of Anonymous Types (and therefore their names) are not visible to the programmer (hence the name 'Anonymous Types'), the programmer can only work with the Object that results of the construction of an Anonymous Type.
  • Anonymous Types are supported only as local Variables.
• Anonymous Types are a 'compiler trick' (and as such work even with the .NET 2.0 Runtime - see [11]).
• Usage: see Details below.
• Usage example in OpenPetra source code: none yet.
• Details: [12]

Partial Methods

• Partial Methods complement Partial Classes. They are methods that enable lightweight Event handling.
• Partial Methods consist of a defining declaration and an optional implementation declaration.
  • There must be exactly one defining declaration and - if there is an implementation declaration - then there must be exactly one as well.
  • These definitions don't have to be in the same Partial Class declaration.
• The most useful application for the use of Partial Methods lies in code generation, where the code generator can always generate code for Event calls and there might in the end be no implementation for the Event - that is something that is allowed only with Partial Methods.
• Partial Methods are a 'compiler trick' (and as such work even with the .NET 2.0 Runtime - see [13]). What happens is the following:
  • In case there is no implementation declaration of a Partial Method, then the Compiler will not emit Intermediate Language (IL) to the Assembly for the Event calls and also not for the defining declaration of the Partial Method. Because of the latter, consequently no evaluation of the Method Arguments will occur in the resulting IL (that is not quite obvious as it happens 'behind the scenes').
  • Since this optimisation occurs at compile time, it cannot be used for techniques which require evaluation at runtime, e.g. plug-in scenarios.
• Partial Methods have some similarity to Conditional Methods, [14], but there are important differences. A good discussion on this can be found in the video mentioned below [15]. The most important distinction is that Conditional Methods rely on compiler directives to be defined, Partial Methods don't (which makes Conditional Methods more suitable for distinction of e.g. DEBUG and RELEASE builds).
• Rules for Partial Methods
  • Partial Methods must be declared within partial Types - Classes or Structs.
  • Partial Methods are indicated by the partial modifier.
  • Partial Methods must be private.
  • Partial Methods must return void.
  • Partial Methods do not always have a body.
  • Partial Methods can be static.
  • Partial Methods can be generic.
  • Partial Methods can have arguments (including this, ref, and params modifiers) - but no out arguments!
  • Partial Methods cannot implement interface methods, neither implicitly or explicitly (reason: because they must be private).
• Usage:
  • If a Partial Method does what you want in a given circumstance, then you should use it instead of an Event, because they are better.
    • Reasons for that:
      • Better performance: Calling a Partial Method simply results in a Method call, and is not using the MS Windows infrastructure to dispatch an Event.
      • Less 'plumbing code' needs to be written (no need for the code that raises the event [On... Methods], no checks needed in those Methods whether there are Event subscribers) --> less Intermediate Language (IL) is emitted to the compiled assemblies.
      • More efficient Intermediate Language (IL) is emitted to the compiled assemblies if Partial Methods aren't implemented, as they are optimised away altogether in that case.
    • Reasons for using Events instead of Partial Methods:
      • Events can be declared in any Class, not just in Partial Classes as is the case with Partial Methods.
      • Events can be declared in an Interface, Partial Methods can't.
      • Events are multicast (0..n subscribers to an Event)
      • Events can have access modifiers (public, ...)
      • Events can be hooked to ('Subscribed to') from any Class, not just the Class where the defining declaration ('Publisher') is found. The Event Handler can again be in a different Class. (This means that the definition, the hooking-up and the Event Handler can be in different assemblies altogether.)
      • Event Subscribers can not only be instance and static Methods as with Partial Methods, but also Anonymous Methods and Lambda Expressions!
      • Events can be hooked to dynamically at runtime (e.g. in plug-in scenarios)
  • More usage guidelines: see the articles in Details section below, and the video that is mentioned below.
• Usage example in OpenPetra source code: none yet.
• Details: [16], [17] and [18], [19] (the last one is quite in depth, with a lot of short examples, also comparing Partial Methods with Conditional Methods)
  • Video: [20] (15 minutes runtime, recommended)

Lambda Expressions

• Replace Anonymous Methods, which were new in C# 2.0.
• Lambda Expressions are a 'compiler trick' (and as such work even with the .NET 2.0 Runtime - see [21]).

C# 4.0

• see http://www.codeproject.com/KB/cs/CSharp4Features.aspx
• see http://soumya.wordpress.com/2009/06/12/new-features-in-c-part-iii-c-4-0/

Named Parameters

• This looks most interesting for us.

Optional Parameters

• This looks very interesting for us, too.

COM Interop

• Probably not interesting for us as the OpenPetra Client should stay platform-independent (COM is available only on Windows OS's).
• Could potentially be useful for optional plug-ins for the OpenPetra Client that would need COM to fulfill their roles, though. Obviously those plug-ins would work on only Windows OS's then.

Mono and new C# features

TODO