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).
• 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: [1]

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).
• Usage example in OpenPetra source code: used already in the web server for the Conference back-end.
• Details: [2]

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.
• 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: [3], [4]

Collection Initializers, Dictionary Initializers

• Similar to Object Initializers, but for the initialisation of values of Collections or Dictionaries.
• Usage: see Details below.
• Details:
  • Collection Initializers: [5]
  • Dictionary Initializers: [6]

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.
• Usage: see Details below.
• Usage example in OpenPetra source code: none yet.
• Details: [7]

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.
  • 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 for the defining declaration of the Partial Method and no evaluation of the Method Arguments will occur in the resulting IL!
  • Since this optimisation occurs at compile time, it cannot be used for techniques which require evaluation at runtime, e.g. plug-ins.
• 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: see Details below.
• Usage example in OpenPetra source code: none yet.
• Details: [8], [9], [10]
  • Video: [11] (15 minutes runtime)

Lambda Expressions

• Replace Anonymous Methods, which were new in C# 2.0.

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