Add auto implement feature to C# language
This is a pain to wrap a class by an other, and implement inner class intreface on outer class which is exposed by an inner instance.
My suggestion is for example:
interface IFoo
{
void DoSometing();
int GetOtherThing();
}
class Foo : IFoo
{
void DoSometing() { ... }
int GetOtherThing() { ... }
}
interface IStuff
{
void DoNothing();
void PutSomething(int s);
}
class Stuff : IStuff
{
void DoNothing() { ... }
void PutSomething(int s) { ... }
}
class All : IStuff, IFoo
{
public All(Foo foo, Stuff stuff)
{
Foo = foo;
Stuff = stuff;
}
public Foo Foo { get implements IFoo; private set; }
public Stuff Stuff { get implements IStuff; private set; }
}
Or if we have explixit getters:
public Foo Foo
{
get implements IFoo
{
return this.foo;
}
}
Implements keyword can be added after methods as well if they returns a value:
public Foo GetFooFromSomewhere() implements IFoo
{
return this.other.Foo;
}
Gabor Mezo
shared this idea
4 comments
-
Jindra
commented
I suggested today similar language feature here: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3540220-delegating-language-feature
Unfortunately I did not notice your suggestion before.
It looks to be very similar to your suggestion - the wanted result is the same.
-
Gabriel T. Field
commented
On second thought, agreed. I really miss advanced metaprogrammin features from C#.
-
Qwertie
commented
There are a lot of different cases where people need to wrap an object and forward most of the methods, only changing the behavior of one or two. The majority of situations are known as the "decorator" pattern.
But there is tremendous variety in the kinds of things one might want to do, so I think the solution that makes the most sense is a compile-time metaprogramming feature that lets you add these kinds of features to C# yourself.
-
Nicole Calinoiu
commented
While I also think that a mechanism for facilitating interface implementation via composition would be a great idea (https://connect.microsoft.com/visualstudio/feedback/details/526307/add-automatic-generation-of-interface-implementation-via-implementing-member), I have reservations about the proposed mechanism. It feels a bit a "inverted" from the point of any reader of the code, such as a code reviewer or maintainer, who shouldn't have to go digging through the entire class contents to find the implementing member. Might it not be preferable to specify the mapping to the implementing member in the class declaration? e.g.:
public class All : IStuff(this.Stuff), IFoo(this.Foo)
{
//...
}Failing a mapping mechanism at the class level, an attribute would perhaps be a better choice than a keyword for indicating an implementing member since it would allow use of a field as an implementing member, and it would be less likely to be "hidden" in a collapsed region. e.g.:
public class All : IStuff, IFoo
{
[Implements(typeof(IStuff))]
private readonly IStuff _stuff;[Implements(typeof(IFoo))]
private readonly IFoo _foo;//...
}Also, it would be very useful if the mechanism were to support a "manual" override for a subset of the interface implementation. (i.e.: The mechanism shouldn't generate a member for a mapped interface if it already finds an implementation in the class.) For example, if All's implementation of IFoo.DoSomething should do a bit extra, one should be able to simply add an IFoo.DoSomething method in All's code without having to opt out of the rest of the "auto-composition" mechanism.
