Feature request: traits

[StefanBertels]

Found this old blog post via StackOverflow:

https://codecrafter.blogspot.com/2011/05/nroles-experiment-with-roles-in-c.html

It's about "adding" features to classes without (mis)using inheritance but by using composition with delegation.
Sadly C# requires me to implement all member explicitely.

Could this be done (in a reasonal way) by LanguageExt? CodeGen using partial classes...

Seems that default interface methods don't solve (parts of) this issue in a practical way because I would have to cast the class to the feature (trait) I want to use.

I see a lot of possible use cases.

[louthy]

Traits are valuable because we want to define a shape to a type, so we can write parametric functions that take those shapes.

So when we write:

    static bool IsEqual<A>(A x, A y) where A : IEquatable<A>

We're stating we want the A to have a equality trait.

Code-generation doesn't allow types to be extended like this in a reasonable way.

Ad-hoc polymorphism is possible, I document how to do it on the home-page, this is effectively the same as traits in Scala, or Type-classes in Haskell. The limitation then becomes the lack of higher-kinded types, which makes traits like Functor and Monad very hard to define, and even harder to use.

It works well for lower-kinded types though. For example Monoid<A>:

    // Semigroup is the base of monoid
    public interface Semigroup<A>
    {
        A Append(A x, A y);
    }

    // Monoid gains a unit element
    public interface Monoid<A> : Semigroup<A>
    {
        A Empty();
    }

With the 'traits' defined, we can then create instances of those traits (which must be structs):

   public struct MString : Monoid<string>
   {
        public string Empty() => "";
        public string Append(string x, string y) => x + y;
   }
   public struct MSeq<A> : Monoid<Seq<A>>
   {
        public string Empty() => Seq<A>();
        public string Append(Seq<A> x, Seq<A> y) => x + y;
   }
   public struct MProduct : Monoid<int>
   {
        public string Empty() => 1;
        public string Append(int x, int y) => x * y;
   }
   public struct MSum : Monoid<int>
   {
        public string Empty() => 0;
        public string Append(int x, int y) => x + y;
   }

We can then define a polymorphic function that takes a trait like so:

    static A Concat<MonoidA, A>(params A[] xs) 
        where MonoidA : struct, Monoid<A> =>
            Seq(xs).Fold(default(MonoidA).Empty(), (s, x) => default(MonoidA).Append(s, x));

That shows that MonoidA is expected to conform to the trait Monoid<A>, and that it must be a struct. This means we can call default(MonoidA) and get a non-null value that contains the functionality of a Monoid<A>. And so, we didn't need to change A, or give add any extra interfaces to its inheritance hierarchy, or cast anything; we simply expect an additional generic argument that has those additional traits.

This means we can then build ad-hoc functionality:

    var r1 = Concat<MProduct, int>(1, 2, 3, 4, 5);                 // 120
    var r2 = Concat<MSum, int>(1, 2, 3, 4, 5);                     // 15
    var r3 = Concat<MString, string>("Hello", " ", "World");       // "Hello World"
    var r4 = Concat<MSeq<int>, Seq<int>>(Seq(1, 2, 3), Seq(4, 5)); // [1, 2, 3, 4, 5]

This I believe is the basis of what the csharplang team are doing with the Shapes/Roles/Concepts/etc. proposal. But I wouldn't expect anything soon.

I have been thinking about this technique more recently (especially as I don't expect something in C# for a long time); and I have been thinking about how awkward this technique is to use. You'd want to be really keen on writing something super-generic to put up with this (lots of generic arguments). I had considered something a little less onerous, which would use the type-resolution system that EqDefault and OrdDefault use for the collection types. The problem with expanding this approach is that it's hard to debug and you don't get compile time errors. Therefore I doubt I'll chase this avenue, unless I feel higher-kinds are a long way off.

[StefanBertels]

Thank you for explanation. Documentation/help of this kind is a good thing, helps a lot.

Probably I wasn't clear enough or just mis-use 'trait' here (or just think into the wrong direction).
I was aware of that ad-hoc polymorphism option. What I'm searching is probably different.

I'm looking for a way to build e.g. a class MyFilestream that gives me all members of FileStream plus my own addition by using composition instead of inheritance. This would allow the use of e.g. sealed things as "base" or something like multiple inheritance. Basically I just want to avoid typing a lot of dumb code.

Example:

    [SomeAttributeActivatingCodeGen]
    partial class MyFilestream : Stream, IDelegateTo<Filestream>
    {
         Filestream _baseStream;

         public MyFilestream(FileStream baseStream)
         {
              _baseStream = baseStream;
         }

         public FileStream IDelegateTo<FileStream>.GetInstance() => _baseStream;
    }

Some helper interface (e.g. in LanguageExt) for this:

   interface IDelegateTo<T>
   {
        T Get();
   }

Then code gen would process each class implementing some IDelegateTo<T> (or defining some corresponding attribute or the like) and create a method/prop-accessor for every public method/prop-accessor of T.

This would e.g. be:

    partial class MyFilestream
    {
         public bool CanRead => IDelegateTo<Filestream>.Get().CanRead;
    }

Already defined functions would be skipped (or get some other, internal name, so they could be called like base methods).

The whole point or this is that I want to inherit the methods / properties of some base type (or interface) but don't want to use inheritance. If I supply my own logic for generating the instance (_baseStream) this could be used with any type (including interfaces). This would make it a lot easier to compose new types based on other types / type snippets.

Note: If you look at the example you see that I inherit from Stream. I could omit this or replace it by e.g. my own interface (could be a subset of Stream like IReadStream).

Two things I have a mixed feeling:

1. Feels strange that I rely on some "invisible code" (generated code) to implement methods (if I define base class / interface ...). But at least we just call the original function so the generated code should neither fail nor do something unexpected.

2. Having to deal with the constructor myself, storing the base ref myself and implementing that Get method seems overhead. But I think it will make things flexibel. I'm not sure whether e.g. Record code-gen could/should do all of this in an integrated way. But if you think about this, we could write:

[Record]
class Address
{
   public string City{get;}
}

[Record]
[AddEverythingFrom(Address)] // pseudo code ...
class Contact
{
   public string First {get;}
}

var x = Contact.New("Village", "Joe");
var city = x.City;