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]

Partial Methods

• Available in Partial Classes only.

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