generic method substitutions and unification

re: generic method substitutions and unification

Thomas Danecker — Wed, 13 Feb 2008 22:40:21 GMT

Thanks for the greate post!

I just want to add that that's a typical multiple-inheritance problem. IMO, whenever there's an ambiguity, the compiler should treat it as invalid code. This way, you'll also eliminate the possible ambiguity of the writer's intention when you read his code. The CLI spec does a good job here.

We've always the possibility to explicitly implement the methods and create a new method with clear definitions of our intentions when we run into such problems.

Keep blogging!

Thomas

re: generic method substitutions and unification

samng — Tue, 19 Feb 2008 21:06:21 GMT

Hi Thomas,

The problem with treating all ambiguity as invalid code however, is that there are many cases where ambiguity is hard to avoid, and yet we want some tie-breaking rule to allow us to write seemingly unambiguous code, and yet have it work in a consistent manner. For instance, the overload resolution rules are a fairly complex set of rules that define exactly how to deal with ambiguities, so that we dont have to have different method names for every overload that we'd like to have.

While I agree that its often nice to name methods clearly, sometimes its unavoidable to have overloads (overloaded operators for example). Dont get me wrong - I'm definitely in the camp that prefers methods named descriptively and without abbreviations, but there are definitely times where simply overloading the parameters is descriptive enough.

Thanks for your comments!

- Sam

re: generic method substitutions and unification

fjeannin — Tue, 26 Feb 2008 16:32:50 GMT

To me, this similar (in a more sophisticated way) to the inconsistency you can create with the 'new' keyword:

//Illegal in C#, will not compile

class Z{

private void Display(){ Console.WriteLine("private Display"); }

public void Display(){ Console.WriteLine("public Display"); }

}

--------------------------------------------

//Will compile just fine and produce an equivalent result to the illegal bit above

class Program {

static void Main(string[] args) {

B b = new B();

b.Display();

}

class A {

public void Display() {

Console.WriteLine("from A");

}

class B : A {

new void Display() {

Console.WriteLine("from B");

}

re: generic method substitutions and unification

Kirill Osenkov — Thu, 28 Feb 2008 11:43:34 GMT

Hi Sam,

Nikov's real name is Vladimir Reshetnikov and yes, he is amazing at finding such things. You can read more at

http://nikov-thoughts.blogspot.com/

Kirill

re: generic method substitutions and unification

samng — Tue, 04 Mar 2008 07:37:13 GMT

Hi fjeannin,

You're absolutely right about the scenario you described. That is exactly the purpose of the "new" keyword when specifying methods on derived classes. The behavior that you're contrasting this to is different. Consider the following example:

using System;

class A

{

public void Foo()

{

Console.WriteLine("A");

}

class B : A

{

public new void Foo()

{

Console.WriteLine("B");

}

static void Main(string[] args)

{

B b = new B();

A a = b;

a.Foo();

b.Foo();

}

This program prints out "A" followed by "B". This is exactly what the new keyword is for - to specify that whatever type the reference is that you're using, thats the method that will get called. Notice that if the methods were declared virtual and override respectively, we would produce "B" followed by "B" instead.

Community Convergence XLI

Charlie Calvert's Community Blog — Wed, 12 Mar 2008 00:41:22 GMT

Welcome to the forty-first Community Convergence. The big news this week is that we have moved Future