Class based projection

[ericsink]

Personally, I rather like the interface-centric way that things are projected to Swift here in this repo.

But certain parts of "The WinRT Type System" page describe a different approach:

Language projections are expected to project a runtime class as a single entity, rather than as a bag of interfaces that the developer has to deal with separately.

To achieve this class-based model, language projections are expected to project type members from a class's member interfaces as direct class members. Language projections are expected to project type members from a class's static interfaces as static class members. Finally, language projections are expected to project activation methods (direct activation as well as interfaces from factory and composable factory interfaces) as class constructors.

(from https://docs.microsoft.com/en-us/uwp/winrt-cref/winrt-type-system)

And I do assume that most developers would fine that style of projection to be more intuitive.

@compnerd It seems you constructed this demo repo as a prototype to discuss how WinRT might look when projected to Swift. Any thoughts on this notion of projecting WinRT runtime classes as Swift classes?

[compnerd]

The "bag of interfaces" is needed to actually expose the interface as a COM type which underlies everything in WinRT. The Swift object layout is not bit-for-bit compatible with C, and the approach I took was to minimise that difference. The composed interfaces still effectively represents this.

If a pointer is "passed over the wire" you will not be able to take that and go, this maps to this class. Instead, we need to take that as a COM pointer of a particular interface (likely IUnknown) and then use QueryInterface to get the appropriate adjusted pointer for each interface and rebind and materialize a singular object from that.

The class inheritance will give you a singular view and de-duplicate the shared interfaces and effectively does accomplish what they state as "project a runtime class as a single entity, rather than as a bag of interfaces that the developer has to deal with separately". That is, when you interact with the object, I think that you would see a single class type that has the full interface. So I assume that you meant more about the initializer (which is the closest thing to a constructor). The thing is, we do have those constructors, they are just not exposed to the user (i.e. we hide the IUnknown * conversion to say ISystemIdentificationStatics).

Is there something specific that you were thinking about and find that this approach diverges from the recommendation? The one piece which it doesn't do is the have a non-parameterised class initializer for the class activation instead relying on the statics. Removal of the statics in favour of the initializer is definitely possible, but may be more expensive (i.e. you may end up with multiple calls to the activation and thus more objects constructed).

[ericsink]

I think I can paraphrase your reply as saying "yes, I planned to project classes".

For example, when you said:

then use QueryInterface to get the appropriate adjusted pointer for each interface and rebind and materialize a singular object from that

and

That is, when you interact with the object, I think that you would see a single class type that has the full interface.

that all sounds like what I was envisioning. I just wasn't sure if you planned to continue in that direction. And if you did not, then I was going be curious about the reasoning.

Since you mentioned statics, I'll briefly observe that one problem I've had is what to do when there are multiple static interfaces for a runtime class. In your pattern, you exposed the static interface under the runtime class name, so its methods look like static methods on the class, as they should. But well, some classes have more than one. For now, I've just exposed each one under a different name. Ugly. I'll need to composite them together.

One example that motivated my original question is Windows.UI.Xaml.Application. The intended design for an object oriented language projection is for the user to subclass, so that things like OnLaunched can be overridden. Under the hood, those are in an interface called IApplicationOverrides. And there's an IApplicationOverrides2 as well. Dealing with these things as strictly interfaces would probably be considered not-very-ergonomic.

Bottom line: It seems like we both agree in principle, and with the statements I quoted above from "The WinRT Type System": Yes, a runtime class should be projected as a Swift class, and the current interface stuff is simply a necessary piece, and a step on that path.

[compnerd]

Yes, this was exploratory work. It has much to be done still, and is leading towards a path to that. My own desire was to expose the Xaml islands via Swift, so seems like we are both aligned on the WinUI (application) bits as well.

[ericsink]

I see now that this was a bit of a silly question. I started this adventure with very little experience with WinRT APIs. I see now that the interfaces are really just an implementation detail, and the runtime classes are what users actually use.

I've got this working for a bunch of cases now, and things end up looking pretty good in Swift:

@main
class HttpClientDemo {
  public static func main() async throws {
    try RoInitialize()

    let httpClient = try Windows.Web.Http.HttpClient();
    let requestUri = try Windows.Foundation.Uri(uri: "https://ericsink.com");
    let httpResponse = try await httpClient.Get(uri: requestUri)!;
    let _ = try httpResponse.EnsureSuccessStatusCode();
    let httpResponseBody = try await httpResponse.Content!.ReadAsString();
    print(httpResponseBody);
  }
}

I do wish the metadata would give me nullability info for parameters and return values. Too many !.

[compnerd]

Ah, I didn't realize that you were expecting the interior APIs to be visible. Yes, the Runtime structure is the API surface.

The WinMD metadata should give you the details about nullability IIRC - the thing is, it should be nullable unless otherwise indicated as the API surface is C.