2 questions about the extension methods in C# 3.0

[Samuel Siren]

Have just read about LINQ ant the new planned features of C# 3.0.
I think it's fantastic, but I have a few questions about extension
methods:
Question 1: Syntax
------------------
Why is the syntax for an extension method like this:

public int ExtMethod(this MyType t, int i, double d) { // t is this
t.I = i;
t.D = d;
}

instead of

public int ExtMethod(MyTyp e this, int i, int j) { // this is this
this.I = i;
this.D = d;
// or just:
I = i;
D = d;
}

? Then the body of an extension method would have the same
"pattern" as an ordinary instance method, which of course would
be ab advantage. So why didn't MS do it that way?
Question 2: Extending to interfaces?
------------------------------------
I realize that the primary purpose of extension method is LINQ, but
if you could also extend types "into interfaces", life would be much
easier also in other situations. Assume the following interface and
class:

public interface ICirkle {
public double R {get; set;}

}
public class Cirkle: ICirkle {...};

Now assume that someone adds this interface and this class:

public interface IEllipse {
public double R1 {get; set;}
public double R2 {get; set;}
}
public class Ellipse: IEllipse {...};

We then also want to be able to treat a cirkle like an ellipse. This
could hyphotetically be done by Cirkle being able to be "extended
into" IEllipse, with e.g. this syntax:

public static class ExtendCirkleInt oIEllipse: Cirkle =IEllipse {
public double R1 {
get {
return R;
}
set {
R = value;
}
}
public double R2 {
get {
return R;
}
set {
R = value;
}
}
}

This would mean that in every piece of code where ellipses are
handled, cirkles could be treated as ellipses. Kind of "backward
inheritance".

This is actually a very common situation, and it kind of "puts
oo on it's head": The common case (e.g. cirkle) is the simple
case, and the more general case is the complex and less usual.
I.e. what's logically a "subclass" needs _less_ data than the
base class.

So, does MS have any ideas in that direction?

/Samuel

[Mattias Sjögren]

Samuel,

>? Then the body of an extension method would have the same
"pattern" as an ordinary instance method, which of course would
be ab advantage. So why didn't MS do it that way?

I don't know for sure why, but I like the current syntax better than
yours. Extension methods must be static, and up to now the this
keyword couldn't be used in static methods bodies. Your suggestion
would need to change that.

Also, just typing

I = i;

could be ambiguous if there was a static field or property named I in
the extension method class and also an instance field or property
named I in the extended class.
Regarding your second queston. Why not just implement IEllipse
directly in the Circle class? Or if you don't control the Circle
class, write a simple adapter class implementing IEllipse and
delegating to ICircle.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Samuel Siren]

In article <uS************ **@TK2MSFTNGP02 .phx.gbl>,
ma************* *******@mvps.or g (Mattias Sjögren) writes:

Regarding your second queston. Why not just implement IEllipse
directly in the Circle class? Or if you don't control the Circle
class, write a simple adapter class implementing IEllipse and
delegating to ICircle.

Ok, I'll giv another example:

Suppose this pattern:
struct DateValuePair {
Date date;
double value;
}

public interface IMyValues {
public double getValue(Date date);
}

public class MyValues: IMyValues {
private InterpolationMe thod method;
private DateValuePair[] points;

public double getValue(Date date) {...}
}

Normally, you'd call it this way:

value = x.getValue(date );

However, assume that we from time to time have a simlple case where the
"MyValues" is just represented as double, i.e. the date-value structure
is "flat", e.g. a flat yield curve of interest rates.

In that case, we would like the double to behave as an IMyValue, i.e.
to return itself when the IMyValues.getVa lue is invoked on it, i.e.
x.getValue(date ) returns x when x is a double.

Now when I'm writing this, though, I realize that this might also
work if there is an implicit cast from double to an IMyValues, e.g.

public class DoubleMyValues: IMyValues {
private double value;
public DoubleMyValues( double value) {this.value = value;}
public static implicit operator DoubleMyValues( double value) {
return new DoubleMyValues( value);
}
public double getValue(Date date) {return this.value;}
}

I'm relatively new to this kind oc casting in C#, so I'm not sure
it would work in all situations. In the test program i wrote i did
NOT work, there was no conversion from double to DoubleMyValues.
(Isn't implicit casting supposed to do just that??)

/Samuel