Proposal: Split async methods into separate interfaces?

[JesseTG]

Some storage backends only support synchronous APIs. Some only support asynchronous APIs. Would it be possible to divide interfaces that have methods for both into synchronous and asynchronous versions?

[dre0dru]

@JesseTG Hello! Can you please provide more info on how you view this? As I understand you are talking about IFileStorage and IPlayerPrefsStorage and they support async and sync API which is defined mostly by underlying ISerializationProvider. Default package implementation (UnityJsonSerializationProvider) indeed provides only sync API for serialization, but some serialization libraries like UT8Json provide async API, too. Also IDataTransofrm implementations that can be used with ISerializationProvider also have async API.

Right now my only thoughs are something like this:

interface IFileStorage {
//sync API + utility methods
}

interface IAsyncFileStorage : IFileStorage {
//addintional async API
}

class FileStorage : IAsyncFileStorage {
// both async and sync implementation
}

The same for IPlayerPrefsStorage.
This way, e.g., you can bind instance to sync or async interface.
Maybe you can provide use case where you need that kind of separation if I misunderstood you?

[JesseTG]

No, you understand me correctly.

I don't have a specific use case right now, since I happen to almost exclusively use asynchronous storage APIs in my project, but I'm trying to think a step ahead. Maybe just keep this idea in your back pocket? Honestly, if you had discussions enabled I'd have mentioned this there instead of opening a ticket.

[JesseTG]

Pretty much. Since as it exists right now, new implementations would have to support both interfaces, which may not always be possible.

Although item 3 would just be items 1 and 2, so really it would be two sets of APIs.

[dre0dru]

@JesseTG Created preliminary PR for this feature. Can you check it?
Basically, all interfaces are split into two:

interface IInterface
{
//sync API
//core utility methods if present
}

interface IInterfaceAsync : IInterface
{
//async API
}

This way you can use either sync or sync+async API depending on what iterface your implementation depends on.

I am still thinking on what to do with implementations, that doesn't really support async API. E.g. UnityJsonSerializationProvider. Right now async API implemented as fake async by returning completed Task with result from sync API. Unity doesn't have an async json serialization API, and I don't really want to put tons of different implementations in package to support all combinations of async/fake async/sync dependencies, so implementations are subject to change.

Btw, do you have any examples where that kind of sync/async API separation implemented? I really like that idea, just don't know how to cleanly implement it with minimal amount of classes in package.

[JesseTG]

@JesseTG Created preliminary PR for this feature. Can you check it?
Basically, all interfaces are split into two:

interface IInterface
{
//sync API
//core utility methods if present
}

interface IInterfaceAsync : IInterface
{
//async API
}

Some cloud storage APIs only work asynchronously, so I'd go with something like this:

interface IInterfaceSync
{
}

interface IInterfaceAsync
{
}

interface IInterface : IInterfaceSync, IInterfaceAsync
{
}

This way compatibility is a compile-time issue; if a cloud storage service doesn't provide synchronous APIs, an implementation can simply not use IInterfaceSync instead of throwing NotSupportedExceptions all over the place.

Put another way: if .NET provides IReadOnlyCollection<T>, then why does ICollection<T> provide a IsReadOnly property? If that property needs to be true, then why not just implement IReadOnlyCollection<T> without also implementing ICollection<T>?

Both IInterfaceSync and IInterfaceAsync can define the same set of common methods, and a class that defines both can just implement them once (unless they'd like to implement both with explicit implementations).

I am still thinking on what to do with implementations, that doesn't really support async API. E.g. UnityJsonSerializationProvider. Right now async API implemented as fake async by returning completed Task with result from sync API. Unity doesn't have an async json serialization API, and I don't really want to put tons of different implementations in package to support all combinations of async/fake async/sync dependencies, so implementations are subject to change.

That's okay, just implement the synchronous APIs and provide extension methods to make them async. Something like this:

public static class SerializationExtensions
{
    public static UniTask<byte[]> SerializeAsync<T>(this ISerializationProviderSync provider, T data)
    {
        return UniTask.FromResult(/* etc */);
    }
}

If an extension method and an instance method with the same signature exist, the instance method will be prioritized.

Btw, do you have any examples where that kind of sync/async API separation implemented? I really like that idea, just don't know how to cleanly implement it with minimal amount of classes in package.

Sort of. MessagePipe comes to mind (see this section), but it doesn't provide interfaces that offer both sync and async APIs.

[dre0dru]

Now I managed to implement it right I think 😁
New version is out, some namespaces are changed, so expect compile errors on update.

[JesseTG]

Thank you, I'll give it a try tomorrow and let you know how it goes!