[Feature request] Dynamic Interfaces

[MHanafy]

When working on large codebases, sometimes there's a need to work on a large set of classes that all shares a common set of properties.
The typical solution is, to create a new interface, and make all these classes implement it; then refer to them through the interface.
While this's sometimes doable, the larger the codebase the harder it's to do.

I'm thinking about a simple solution, where C# allows a dynamic interface; then when using type comparison/casting to a dynamic interface; the class simply needs to match the interface members without a need to change the original class.

This will be very useful in maintaining large, long running projects that has a lot of classes.

class Supplier{
    public string Name {get; set;}
    public string EMail {get; set;}
    //--- Other irrelevant attributes
}

class Employee{
    public string Name {get; set;}
    public string EMail {get; set;}
    //--- Other irrelevant attributes
}

class MissingProps{
    public string Name {get; set;}
    //Note that EMail is missing
}

dynamic interface IContact{
    string Name {get; set;}
    string EMail {get; set;}
}

public static void Main(){
    var supplier = new Supplier{Name = "SomeName", EMail = "[email protected]" }
    var employee = new Employee{Name = "AnotherName", EMail = "[email protected]" }
    var missingProps= new MissingProps{Name = "ThirdName" }
    // below calls are successful because interface resolution is done dynamically,
    // since Supplier and Employee has the right signature
    var iSuppContact = supplier as IContact; 
    var iEmpContact = (IContact) supplier;

    //below call fails because of missing properties
    var iMissingProps = (IContact) missingProps;
}

[HaloFour]

I think #110 (shapes) would cover this.

[svick]

I don't see why this needs to be a language feature. You can use a library like like ImpromptuInterface instead:

var iSuppContact = supplier.ActLike<IContact>();

ImpromptuInterface does not throw an exception from ActLike when a member is missing, instead it throws when you attempt to access that member. But you could write a library that behaves the way you want.

[MHanafy]

@svick Yes, this approach can be used; the benefit of having this as a language feature is having compile time checks; the code won't compile until the classes matches the interface.

[svick]

@MHanafy That sounds like something that could be done with a Roslyn analyzer.

[Joe4evr]

the benefit of having this as a language feature is having compile time checks; the code won't compile until the classes matches the interface.

That's exactly what Shapes are all about.