I suggest you ...

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;
}

59 votes
Vote
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Gabor Mezo shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thanks for taking the time to share this suggestion. This item has been around for a couple of versions of Visual Studio and we haven’t acted on it. Looking at the VS “15” plans, we’re not going to take action on this item, so we’re going to close it. If the suggestion is still relevant, please either take a look to see if there’s another suggestion that’s similar that you can vote on, or open a new suggestion.

- The Visual Studio Team

7 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • Tzach Shabtay commented  ·   ·  Flag as inappropriate
  • Michal Turecki commented  ·   ·  Flag as inappropriate

    This seems to be the most missing core c# feature which when implemented would save much development time.

    Microsoft's reservations behind implementing auto generating interface proxy methods are probably because the actual proxy implementation is hard to make everyone happy:

    1. Add null checking or not?

    2. What if implementation needs to be a weak reference?

    3. Throw exception or do nothing if implementation is null

    4. When multiple "implements" members share the same base interface, which instance shoult be called and in what order (multiple inheritance problem)

    Possibly more.

    I still voted 3 of my points for this feature because personally I think implementation should be as simple as it can:

    1. No null checking - optimistic approach

    2. No weak references, these can be done in the class implementations

    3. No exceptions other than from "implements" methods, getters and setters

    4. Shared interfaces can be either forbidden in the first release of this feature or shared base interface implementations should be forced on a developer: "Interface IBase needs to be explicitly implemented on FooBar because it is shared between following interfaces: IFoo IBar.

    As Nicole Calinoiu partial implementations can be a good thing to prevent spaghetti code. Hopefully somebody will add this syntactic sugar to the Roslyn compiler. Or one of us will :)

  • Qwertie commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

Feedback and Knowledge Base