[Proposal] Extension classes with Interfaces

[grwGeo]

I believe that type extensibility (as in extension methods) is a very useful feature that should be viewed as part of a healthy OOP design and not just as compiler deception or syntactic sugar.

Type extensibility can be expanded to the much anticipated extension properties, extension events, indexers etc and even Interface implementation. This last one would be particularly useful should we need to group types owned by others, in interfaces owned by us (or others).

The main advantage of type extension is the ability to intervene high up in an inheritance chain, adding extra functionality to a multitude of types with just one stroke (e.g. imagine adding a custom property to all windows forms controls with just a few lines of code). And with the addition of implementing interfaces this can be a very powerful tool.

I have personally indirectly implemented extension properties and events, so it should be logically consistent to implement these.

A syntax for all these could be similar to partial classes and this could replace current syntax for extension methods as well. So something like this (interface optional of course):
(Here is code)

public extension class OtherOwnersNamespace.OtherOwnersClass : ISomeInterface
{
    private int _myExField = 0;
    public int MyExProperty { get { return _myExField; } }

    public event EventHandler<EventArgs> MyExEvent;  //Could add accessors too.

    internal void MyExMethod() { }
    protected virtual void MyExVirtualMethod() { } //Could be overridden in an extension of an OtherOwnersDerivedClass  
    public static void MyExStaticMethod() { }

    public string this[object someObject] { get { return someString; } }


    void ISomeInterface.SomeInterfaceMethod(){}
}

The 'this' keyword should give us all properties of the original class plus our extension class.
The scope and visibility of the extension class and its members would be the same as if the class was defined normally without the 'extension' keyword.

Current syntax could also remain as an alternative to avoid unnecessary lines of code for cases where (for example) lots of different single extension methods for different types are defined and gathered in one static class.

[svick]

I don't think extension interfaces can be implemented reasonably well without CLR support.

The only way I can imagine it would be implemented is if casting to that interface returned some wrapper object. But that would mean ReferenceEquals wouldn't work reliably for such objects. E.g.:

var c = new OtherOwnersClass();                  // c is the original object
ISomeInterface i = c;                            // i is the wrapper object
Console.WriteLine(object.ReferenceEquals(c, i)); // writes "False"

[grwGeo]

I believe that since class extensibility is logically consistent, it deserves to be part of OOP and therefore have full CLR support (not compiler deception). This is what my proposal is aimed at.

[grwGeo]

Readers should understand that this is a two part proposal:

1. Simple class extensibility.
2. Interface implementation extensibility.
   It can be implemented in these two stages and the first stage could be implemented gradually (e.g. an extension class might not support extension events or indexers to start with).

[grwGeo]

Another useful application of interface extensibility is when the interface might require implementation of an already existing member.
E.g. all controls (or base controls) that already have a 'Caption' property might be extended to implement an 'ICaption' interface (if they don't implement one). This would allow us to group them into ICaption types and work collectively with their Caption property.
This would only require the first line of the proposed syntax and with such one-liners we could "register" a multitude of different base controls (i.e. different hierarchies).

[ufcpp]

I' m going to implement the same purpose but somewhat different approach by using a Roslyn code fix provider. I call it "MixinGenerator". (but at this time, this repository contains only test cases: some pairs of an original source and the expected generated result, no implementation.)

The code fix, for instance, will generate a code from

using Mixins.Annotations;

namespace MixinGenerator
{
    [Mixin]
    public struct X
    {
        public string PublicValue => null;

        [Protected]
        public string ProtectedValue => null;

        [Private]
        public string PrivateValue => null;
    }

    public class Sample
    {
        X _x;
    }
}

to

    public class Sample
    {
        X _x;

        public string PublicValue => _x.PublicValue;

        protected string ProtectedValue => _x.ProtectedValue;
    }

If a Mixin struct implements an interface, the code fix will generate a class which implements the same interface.

[paulomorgado]

Just for the benefit of all,. there really isn't such a thing as partial classes. There are partial class definitions; meaning, partial definitions of classes.

[grwGeo]

You are right for 'partial classes' but I think that for 'extended classes', philosophically speaking, you could argue both ways.

I.e. they are 'an extended definition of a class' but they are also an almost (but not fully) independent class of their own (and they would be in cases where they do not refer to any of the original members). Another way of looking at it is that they are 'portions of classes' as almost independent data constructions.

So the extended 'portion' is attached to the original part.

[grwGeo]

Extension constructors should also be possible with the restriction that they call an original constructor and of course they do not conflict with the signature of other existing constructors. Something like:

public extension class OtherOwnersNamespace.OtherOwnersClass : ISomeInterface
{
public OtherOwnersClass(an original set of params, plus a new set of params)
: this(an original set of params){ }
}

[Przemyslaw-W]

@grwGeo what advantage has such extension ctor over factory method?

[grwGeo]

@Przemyslaw-W The whole aim is to treat an extended type just like a normal class, with all the syntax that pertains to a class and all related intellisense.
Creating such extension constructors would constrain consumers of the class to initialize instances in a specific way, as long as it is consistent with the initialization of the original class.

[grwGeo]

I don't know any F# but looking online today I am under the impression that it has advanced type extensibility features (more than C#). Is this true?

[HaloFour]

F# type extensions are really just syntax for either amending a partial class defined in the same module, or for defining extension methods. C# has those same features.

[grwGeo]

So in F# extending fields (properties?) or other members apart from methods in a different assembly (for example) is not possible.

Thanks for the clarification.

[grwGeo]

It might also be possible for extended controls to have full VS designer support. This would be an alternative to inheriting and as described above preferable in cases where we intervene high up in the hierarchy. This might be the basis for the CLR version of the Dependency Properties pattern in WPF.