ClientModel: Convince ourselves that the `virtual` problem isn't a concern about azure-sdk-for-net

[KrzysztofCwalina]

I spent some time thinking about this. It seems to me like the most tricky case is a virtual get-set property on an existing subtype. For example, the Request.Uri property. It seems to me that we can make everything work correctly, if we: a) have just ome source of truth (a filed in the subclass), b) seal Core property/methods in the subclass. For example:

public abstract class PipelineRequest
{
    public Uri Uri {
        get => UriCore;
        set => UriCore = value;
    }

    protected abstract Uri UriCore { get; set; }
}

public abstract class Request : PipelineRequest
{
    RequestUriBuilder? _uri;
    public new virtual RequestUriBuilder Uri {
        get => _uri ??= new RequestUriBuilder();
        set => _uri = value;
    }

    protected sealed override Uri UriCore {
        get => Uri.ToUri();
        set => Uri.Reset(value);
    }
}

public class RequestUriBuilder
{
    public Uri ToUri() => throw new NotImplementedException();
    public void Reset(Uri value) => throw new NotImplementedException();
}

[KrzysztofCwalina]

In the case of get-only properties (e.g. Response.Content) where the type of the property does not change in the subclass, we should do what the notes say, i.e. make the property virtual.

In the case of get-only properties (e.g. Response.Content) where the type of the property does change in the subclass, we should do what the notes say, i.e. use protected Core method.

[KrzysztofCwalina]

Let's implement the combinations of the recommendations (from the table) and the one I added for get-set properties (Request.Uri). Hopefully these will cover all the cases. if you run into another case that is not discussed in the issue, let me know

[annelo-msft]

• We will change the GetXxCore and SetXxCore methods on PipelineRequest and PipelineResponse to XxCore properties.
• Unfortunately, I don't think we are able to seal the XxCore properties as described above, because of the way we use adapters for ClientModel-internal types in the Azure.Core integration. However, since the XxCore methods are new, no one is currently overriding them in a subtype. Since it would be quite advanced to provide derived types of Azure.Core Request and Response, I think we are safe to say that if you override one of the XxCore methods and make it not call through to the template property (the Xx property itself), this is a bug due to not following intended usage patterns. I would prefer if we could have the compiler enforce this for us, but I think this would require making request and response transport implementations in ClientModel public, and I don't think that would be a good trade-off.

[KrzysztofCwalina]

Could you link to adapter code that illustrates how the adapter overrides (or has to override) the UriCore property?

[annelo-msft]

Could you link to adapter code that illustrates how the adapter overrides (or has to override) the UriCore property?

I put a simplification of the problem as I understand it in this gist:

virtual_problem_uri.cs

The adapter implementation in the Azure.Core 2.0 integration PR branch is here:

1. Azure.Core Request newslots Uri
2. Azure.Core Request overrides UriCore -- calling through to the virtual public property on Request
3. Azure.Core internal Request sutype HttpClientTransportRequest UriCore implementation -- the internal implementation must keep the RequestUriBuilder property on the Azure.Core Request and the Uri property on the ClientModel pipeline request in sync with each other so the same value for Uri is available in both the Azure.Core type and the ClientModel type.

[annelo-msft]

Completed with #42010