S
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(MyType 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 ExtendCirkleIntoIEllipse: 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
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(MyType 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 ExtendCirkleIntoIEllipse: 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