Proxy Interface Implementation

[soraphis]

Assume you've got a wrapper class like:

public class MyWrapper<T>{
    public T Wrapped {get; private set;}
}

This could be used like:

interface IFoo{ public void Foo(); }
// ...

MyWrapper<IFoo> FooWrapper;
//....

FooWrapper.Wrapped.Foo();

this has the downside, that you'd always have to call .Wrapped to access the actual stuff. Wheras MyWrapper could - trivially - implement T by passing everything to the Wrapped object.

for example:

public class MyWrapper<T> : T{
    public T Wrapped {get; private set;}

    public static implicit override T(MyWrapper<T> self) => self.Wrapped;
}

note: that this might make more sense, considering that the Wrapped property might have logic in it's getter/setter.

---

---

Edit: to have a bit more clarification:

Imagine you've got an Service class (implementing IService) you want to wrap within a Logging Proxy. IService has far more than 1 method.

to create your logging proxy, you'd create a class like:

public class MyServiceLoggingProxy : IService
{
    private readonly IService realService { get; init; }

   private IService GetRealService([CallerMemberName] string property = "")
   {
      Console.Log($"Calling {property}");
      return realService;
   }

    // implementing IService:
   public void Method_1_Of_IService() => GetRealService().Method_1_Of_IService();
    // .... listing ALL THE METHODS like this
}

now imagine you could SKIP all the trivial IService implementation stuff like i did with "// ...." but have the compiler add the stuff for you. e.g. by using
public class MyServiceLoggingProxy : IService => GetRealService which instructs it to implement IService by forwarding everything to the member "GetRealService"

[ArcadeMode]

What you appear to be suggesting is an operator that allows implicit casting to its own super class, which then returns a different instance. My first intuition is that this sounds like problems. Secondly, this would require some funky dynamic superclassing structure which afaik is fixed after compile time in any typical polymorphism-supporting language, so by my understanding that would require a deep overhaul of the language. It may not even be possible to be consistent from a theoretical point of view.

To address the triviality you mention: inheritance is not necessarily usable here. If say T is a sealed type, this would not work. This would therefore also be a problem of enabling the dynamic extension of sealed types, therefore violating the concept of type sealing.

All in all this idea appears to violate some core language design decisions and you are probably better of implementing a proxy pattern

[soraphis]

What you appear to be suggesting is an operator that allows implicit casting to its own super class

no it has nothing really to do with superclass/subclass. It's about making it possible to wrap an object within an other type which has the same API.

without either the need to explicitly pass every method call to the 'Wrapped' property AND without the need to call the 'Wrapped' property everytime.

my point is exactly that the implementing the proxy pattern means either that your proxy contains LOTS and LOTS of boilerplate (because you're recreating the API of another class) or that you expose the proxied property (thus your proxy isn't transparent anymore).

[CyrusNajmabadi]

that your proxy contains LOTS and LOTS of boilerplate

Sounds like something source generators can take care of.