FVN Tech Blog » dotNET

Peak at C# 4.0: optional parameter, named parameter and method resolution

feuvan — Mon, 12 Apr 2010 18:52:47 +0000

Optional and named parameter is an awesome feature introduced in C# 4.0. Now C# combines some fancy features from dynamic languages like Python again (var knows why I say again. And the more dynamic dynamic is another topic, LOL).

Please note the “NEW:” comment for optional parameter declaration and named parameter assignment.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApp
{
class Program
{
static void Main(string[] args)
{
var top = new TestOptionalParameter();
double d = top.Demo(0); // #1

// int d = top.Demo(0, s: “test”); // NEW: named parameter.
}
}

class TestOptionalParameter
{
public int Demo(int i, string s = “demo purpose”) // #2 NEW: optional parameter declaration
{
Console.WriteLine(“int Demo(int i, string s = \”demo purpose\”)”);
return 0;
}

public double Demo(int i) // #3
{
Console.WriteLine(“double Demo(int i)”);
return 0;
}
}
}

But when combined with method name resolution, unconsidered condition may occur.

Try these changes and you will realize what you’ll pay for fancy new features: (Play it with VS2010. I don’t want to copy and paste several times and just modify one place of return type or variable value.)

Change #1	Change #2	Change #3	Why?
			Works as expected. Matches 2nd Demo method.
change double to int			Easy to understand, the 1st Demo matches better. (Fully match in/out/return parameter, though there’s an optional parameter not specified when invoking the method)
add named parameter. change it to double d = top.Demo(0, s: “test”);			still the 1st Demo matches better. Now named parameter takes place.
		change int to double	Match 1st. No implicit conversion required for parameter.
change 0 to 0.0			Compile error. Explicit conversion required.
change 0 to 0.0	change int to double		Match 1st. No implicit conversion required for parameter.
Whenever add 2nd string parameter, named with “s” or unnamed.			Match 1st.

Some looks-hard-but-actually-straightforward-and-ideal conclusion:

Whenever named or unnamed parameter used, method don’t accept these parameters will be out.
If implicit conversion is NOT required, traditional method resolution goes first, then goes to match methods with optional parameter. (please note there’s some a-bit-evil details to be discussed.)
If implicit conversion is required for parameter or return type, match method with matched implicit parameter first.
When explicit conversion is required or specified error parameter name or value type, compile time error will be triggered.

Let’s guess the trend of IT Tech in the next decade. Part.1

feuvan — Mon, 04 Jan 2010 17:28:02 +0000

Preface

I supposed to write this blog post by the end of the last year, but it was delayed.

These words are just IMHO. And you’ve already been familiar with these words.

XML

About 10 years ago, XML is considered to be one of top 10 technologies that most programmers should master. Today XML is still the most important basis for cross-platform/language/system/blahblah message exchange/interpret. Meanwhile, JSON is becoming more and more popular in Web age for its lightweight. But in enterprise domain and business critical scenarios, XML related technologies provide these feature: flexible (better than JSON), open, robust (better than JSON) and compressible. (one important example: Office Open XML format .aka. ECMA-376, it’s continue evolving along with Microsoft Office products in these years)

Parallel

I’m not talking about cloud. I’m talking about desktop parallel computing. With more and more multiple core CPUs are filling the market, the old programming style will be changed a bit.

The change will involve new compiler, new library (OpenMP for C/C++, .NET FX 4, etc), new language (someone may mention Erlang), and the most important, new programming model or thinking.

Managed

Managed languages like C# and Java will eat more market share from traditional ones. In the next ten years, we may see Native IL support CPU or its work-like-a-product prototype say hi to the world.

Script languages will get benefits from technologies like DLR from .NET. We have seen JPython/IronPython, JRuby/IronRuby, Groovy/PowerShell (well, this pair are not so suitable to compare), and we’ll see more.

Mobile

Netbook? UMPC? PDA Phone? We’ll enjoy a mobile life. From the next generation mobile, we may get more affordable next generation mobile data fee(beyond 3G, LTE), much fast dl/up speed, better signal coverage.

Designers and manufacturers will produce more powerful mobile device, and the meaning of “mobile” will be extended to many devices. More scenes in SF novel/movie will come true.

At the same time, IT system will be more friendly to mobile device. For example, better support for small screen, one hand operation, reader mode, etc.

Universal

I’m talking about OS. We’ll have more choice when choosing OS, Windows, Linux, Mac, BSD…. but they will talk to each other much more smoothly. With Microsoft’s open promise on interoperability, other OS and products can talk to one of the biggest market share holders’ products. People can see their different desktop/server can talk to each other more happily than before.

–

It’s a bit late (1:26AM, GMT+8), Ill try to finish the list in recent days and post it as Part.2

2009: A dynamic future of C#

feuvan — Fri, 31 Oct 2008 08:39:46 +0000

70s coders learn C, Pascal, COBOL(one of the best IT jobs in economic crisis)
80s coders learn C
90s coders learn C++, Java, Delphi
21-century (long time no see this hot word during 1999-2001) coders learn C#?

- A homemade rumor by anonymous craven

On PDC 2008, Anders, former architecture of Turbo Pascal, Delphi, Visual J++, currently the father of C#, gives us a presentation “The Future of C#” about what new features C# 4.0 will have. The demo “Compiler as a service” is really cool. Think about the prompt “C# >”.

Mads Torgersen, C# Language PM gives a public released document on C# Future site, describes four main new features:

Dynamic lookup

Dynamic lookup allows you to write method, operator and indexer calls, property and field accesses, and even object invocations which bypass the C# static type checking and instead gets resolved at runtime.

Named and optional parameters

Parameters in C# can now be specified as optional by providing a default value for them in a member declaration. When the member is invoked, optional arguments can be omitted. Furthermore, any argument can be passed by parameter name instead of position.

COM specific interop features

Dynamic lookup as well as named and optional parameters both help making programming against COM less painful than today. On top of that, however, we are adding a number of other small features that further improve the interop experience.

Variance

It used to be that an IEnumerable wasn’t an IEnumerable. Now it is – C# embraces type safe “co-and contravariance” and common BCL types are updated to take advantage of that.

My comments:

features	benefit	side effect
Dynamic lookup	dynamic (runtime type detection) versus var (compile time type inference) introduced in C#3.0. No handwritten reflection codes any more.	No IntelliSense when programming. Difficult to defend unknown runtime exceptions, errors.
Named and optional parameters	ease function call of COM interop like VSTO, etc.	Named parameters looks Pythonic. But maybe Jim like this?
COM specific interop features	based on previous two new features, it’s easier. The biggest benefit: no runtime PIA more!	N/A? Time to migrate old workaround code.
Variance	more friendly	as above.

These new features certainly relies on new .NET framework. At least, dynamic is not a language sugar like var.

Overall, C# is becoming more and more free-style language, combined compile-time and run-time power. It’s worthy to take a look at what C# will be if you are a C# developer or even a Java, C++ lover. Write less, do more. That’s the best value of the C# evolution, IMO.

Some articles for dotNET developer from MSDN Magazine

feuvan — Mon, 28 May 2007 03:44:31 +0000

Garbage collection:
Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework — MSDN Magazine, November 2000
Garbage Collection-Part 2: Automatic Memory Management in the Microsoft .NET Framework — MSDN Magazine, December 2000
Garbage Collector Basics and Performance Hints — MSDN

widely spreaded article about tools:
.NET Tools: Ten Must-Have Tools Every Developer Should Download Now — MSDN Magazine, July 2004

wix and msbuild:
WiX Tricks: Automate Releases With MSBuild And Windows Installer XML — MSDN Magazine, March 2007

something new:
CLR Inside Out: .NET Application Extensibility — MSDN Magazine, February 2007
CLR Inside Out: .NET Application Extensibility, Part 2 — MSDN Magazine, March 2007
CLR Inside Out: 9 Reusable Parallel Data Structures and Algorithms — MSDN Magazine, May 2007

New Library Classes in "Orcas"

feuvan — Thu, 19 Apr 2007 09:02:48 +0000

.NET Framework 3.5 is scheduled to be shipped with “Orcas” later 2007 or early 2008. “Orcas” is the codename of Microsoft’s next generation of the heavy and effective IDE Visual Studio 2007.

According to Microsoft site, the new .NET Framework has been divided into two parts: red bits and green bits. The red bits is backward-compatible 3.0 netFX libraries, while the green bits is totally new assemblies with some extra new features including:

A new add-in hosting model, which was discussed in the last two editions of CLR Inside Out
Support for the Suite B set of cryptographic algorithms, as specified by the National Security Agency (NSA)
Support for big integers
A high-performance set collection
Support for anonymous and named pipes
Improved time zone support
Lightweight reader/writer lock classes
Better integration with Event Tracing for Windows^® (ETW), including ETW provider and ETW trace listener APIs

Suite B Implementations

Suite B standard is from NSA, including these implementations:

The Advanced Encryption Standard (AES) with key sizes of 128 and 256 bits for encryption
The Secure Hash Algorithm (SHA-256 and SHA-384) for hashing
The Elliptic Curve Digital Signature Algorithm (ECDSA) using curves of 256-bit and 384-bit prime moduli for signing
Elliptic Curve Diffie-Hellman (ECDH) using curves of 256 and 384-bit prime moduli for key exchange/secret agreement

The new .NET Framework provides these implementations, and also a new class named CngKey:

To support our new CNG-based managed cryptography classes, we’ve added a CngKey class to abstract the storage and usage of CNG keys. CNG keys work similarly to key containers in today’s Crypto API (CAPI)—they allow you to store a key pair or a public key securely and refer to it using a simple string name. You can use CngKey objects when working with the ECDsaCng and ECDiffieHellmanCng classes.

You can also use the CngKey class directly to perform many operations, including opening, creating, deleting, and exporting keys. If we don’t have a managed API for the operation you want, you can get to the underlying key handle to use when calling Win32^® APIs directly.

Better Integer Support: BigInteger

Now you can have the BigInteger class with these operation supports:

Abs (returns the absolute value for a given BigInteger)

Compare (compares two BigIntegers)

Divide (returns the quotient of two BigIntegers)

DivRem (returns both the quotient and the remainder of two BigIntegers)

Equals (returns true if two BigIntegers have the same value)

GreatestCommonDivisor (returns the maximum number that is a divisor of both BigIntegers)

ModPow (returns one BigInteger raised to the power of another BigInteger modulo a third; the exponent cannot be negative)

Pow (returns one BigInteger raised to the power of another; the exponent cannot be negative)

Remainder (returns the remainder of dividing one BigInteger by another)

A New High-Performance Collection Class: HashSet

The new class HashSet was added to System.Collection.Generic namespace as a unordered generic high-performance collections that contains unique elements. It implements all the standard collection methods (such as Add, Remove, and Contains) and provides several set operations (including union, intersection, and symmetric difference). It’s easy to use and with high-performance.

Pipes: System.IO.Pipes

Both anonymous and named pipes are supported. Now nearly all the pipe functionality provided by Windows are exposed. Now it’s easy to achieve IPC from managed code. If you have experience with Windows native pipes, you will get no trouble to start with the new managed class.

Conclusion

We can expect more complete .NET Framework covering your industry, commercial, personal development requirements. As Microsoft has been described, .NET Framework will as last cover what Win32 SDK covers. It’s not rumor or business advertisement, I believe managed code will be natively supported by OS one day, neither .NET nor Java, or some other languages.

Developing MSN/WLM Add-in Part.I

feuvan — Wed, 28 Feb 2007 07:50:40 +0000

微软的Messenger SDK分为面向多人应用的Activity SDK和面向单人应用的 Add-in SDK（Windows Live Messenger Add-In API）。不过Live时代的WLM Add-In SDK相较于之前的MSN Messenger API，开放的接口反而少了。自微软实行.NET战略以来，Windows平台应用程序开发的主流逐渐由以往的VC++与Platform SDK搭配的方式转由.NET Framework与C#。然则.NET Framework由于设计的目的与一般普适的Platform SDK并不完全一致或者包容后者，在开发许多real world scenario 下的具体应用时，仍需要依赖Inter OP来使用现有COM组件的接口（关于.NET的本质是COM的论述，实际上也有不少相关文章可供参考，读者可自行利用谷歌雅虎百度搜寻，亦可于水木社区dotNET讨论区的精华文章中寻找。）

事实上，无论是新的WLM SDK，或者旧的Messenger API，皆是安装有WLM后才注册在系统中的COM组件。而WLM Add-in与MSN Messenger API最大的不同，就是开发语言必须是基于.NET Framework 2.0的C#，C++/CLI，VB#，J#，抑或IronPython等脚本语言。本文将会以一个实际的例子来探讨如何以C#来开发WLM的 Add-In。

要启用插件功能，首先需要修改注册表项。在HKCU\Software\Microsoft\MSNMessenger新建DWORD项，名为AddInFeatureEnabled，值设置为1。或者将以下四行文本存为reg文件导入。

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\MSNMessenger]

“AddInFeatureEnabled”=dword:00000001

修改了注册表之后，登录WLM，在Option菜单中就会出现Add-ins选项，点击Add to Messenger，找到Add-In dll就可以加载了

打开VS 2005（亦可使用Visual C# 2005 Express Edition），建立Class Library工程，名为WLMAddintest，添加引用Messenger API（Project，Add Reference，COM，Messenger API Type Library），添加引用Messenger Client（Project，Add Reference，Browse，C:\Program Files\MSN Messenger\MessengerClient.dll）。

将CS文件改名为test.cs，并新建一个名为TestFrm的新窗体。

更改输出assembly的文件名为WLMAddintest.Test（Project，WLMAddintest Properties，Application，Assembly Name）。因为WLM Add-In对于文件名有着严格的限制，必须是namespace.classname.dll的方式，否则将不能加载。当然你可以使用匿名命名空间，这样就可以只生成test.dll让WLM加载。

Frame代码先省略，其中test.cs代码如下：

using System;

using System.Collections.Generic;

using System.Text;

using System.Windows.Forms;

using Microsoft.Messenger;

namespace WLMAddintest

{

public class Test: IMessengerAddIn

{

public MessengerClient m_client;

public Form frm;

public void Initialize(MessengerClient client)

{

m_client = client;

m_client.Shutdown += new EventHandler(this.Shutdown);

m_client.AddInProperties.Url = new Uri(“http://dev.feuvan.net/”);

m_client.AddInProperties.FriendlyName = “test add-in”;

frm = new TestFrm();

frm.Show();

}

public void Shutdown(object sender, EventArgs e)

{

frm.Close();

}

在以上部分代码中，我们建立了一个名为test的类，实现了IMessengerAddIn接口，而Initialize则是Add-In的入口。另外我们绑定了Shutdown事件，Shutdown事件是在Add-In被unload，用户登出WLM或者关闭WLM发生的。读者可以使用VS的Object Browser来浏览MessengerClient提供的接口（选中Reference中的MessengerClient，双击或者右键View in Object Browser）。

MessengerClient类共有五种事件，皆可绑定到自己定义的事件响应函数上。

事件	事件描述	参数描述
EventHandler IncomingTextMessage	文本消息传入时发生	IncomingTextMessageEventArgs有两个属性 string TextMessage和User UserFrom
EventHandler OutgoingTextMessage	文本消息传出时发生	OutgoingTextMessageEventArgs有两个属性 string TextMessage和User UserTo
EventHandler ShowOptionsDialog	用户点击Add-In的Settings时发生	N/A
EventHandler Shutdown	Add-In被unload时发生	N/A
EventHandler StatusChanged	有用户的状态改变时发生，如登入登出。	StatusChangedEventArgs有一个属性 User User

其中User类的属性有昵称，email，个人状态信息，状态，唯一ID，并有一个方法GetGroupNames，可以得到用户所在的组名。

MessengerClient类有三种属性：

属性	限制	作用
AddInProperties AddInProperties	读写	设置Add-In的信息如名称，作者，描述，URL等
User LocalUser	只读	当前登录用户的属性，包括昵称，email，个人状态信息，状态，唯一ID
string SavedState	读写	提供Add-In存储空间。由于WLM Add-In的安全限制，Add-In不能访问本地文件。所以配置等信息可以串行化之后保存在SavedState变量中，下次启动从这里读取。

MessengerClient类有三个方法：

方法	作用
void SendActionMessage(string actionText, Microsoft.Messenger.User userTo)	发送动作
void SendNudgeMessage(Microsoft.Messenger.User userTo)	发送震动信息
void SendTextMessage(string text, Microsoft.Messenger.User userTo)	发送文本

至于这里的User参数，基本上都是相应IncomingTextMessage的时候传进来的UserFrom参数。例如：

void messenger_IncomingTextMessage(object sender, IncomingTextMessageEventArgs e)

{

Microsoft.Messenger.User from = (Microsoft.Messenger.User)e.UserFrom;

messenger.SendTextMessage(output, from);

}

从上面的例子我们可以看到，WLM Add-In SDK还是很弱的，基本上只能拿来写机器人用，当然了，现在MSN机器人层出不穷，也不新鲜了。

接下来，就让我们来看看Messenger API能干点什么，以及更高级的话题。

后续内容更精彩，敬请继续关注。