[Reactive]: redundant ListState.Value overload?

[weitzhandler]

ListState offers several factory methods for creating IListStates<T> (as well as ListFeed), some of which have duplicate overloads for both Func<IImmutableList<T>> (interface) and Func<ImmutableList<T>> (concrete), for example:

uno.extensions/src/Uno.Extensions.Reactive/Core/ListState.cs

Lines 30 to 54 in 68b1506

	/// <summary>
	/// Gets or creates a list state from a static initial list of items.
	/// </summary>
	/// <typeparam name="TOwner">Type of the owner of the state.</typeparam>
	/// <typeparam name="TValue">The type of the value of the resulting feed.</typeparam>
	/// <param name="owner">The owner of the state.</param>
	/// <param name="valueProvider">The provider of the initial value of the state.</param>
	/// <returns>A state that encapsulate the source.</returns>
	public static IListState<TValue> Value<TOwner, TValue>(TOwner owner, Func<IImmutableList<TValue>> valueProvider)
	where TOwner : class
	// Note: We force the usage of delegate so 2 properties which are doing State.Value(this, () => 42) will effectively have 2 distinct states.
	=> ListState<TValue>.Value(owner, valueProvider);
	/// <summary>
	/// Gets or creates a list state from a static initial list of items.
	/// </summary>
	/// <typeparam name="TOwner">Type of the owner of the state.</typeparam>
	/// <typeparam name="TValue">The type of the value of the resulting feed.</typeparam>
	/// <param name="owner">The owner of the state.</param>
	/// <param name="valueProvider">The provider of the initial value of the state.</param>
	/// <returns>A state that encapsulate the source.</returns>
	public static IListState<TValue> Value<TOwner, TValue>(TOwner owner, Func<ImmutableList<TValue>> valueProvider)
	where TOwner : class
	// Note: We force the usage of delegate so 2 properties which are doing State.Value(this, () => 42) will effectively have 2 distinct states.
	=> ListState<TValue>.Value(owner, valueProvider);

What's the reson they both exist, can't we just have only the interface version?
In fact they could all be named Create as their overloads defer.

There are other inconsistensies between the 4 factory classes, for example some don't provide a Func<CancellationToken, ... overload where some do only with one. Can you please explain?

Another one - there are inconsistencies in ListState's extensions, for instance Update and UpdateAsync can be both named just Update as they're different overloads. Also AddAsync and others.

[dr1rrb]

What's the reson they both exist, can't we just have only the interface version?

The T on IImmutableList contravariant (nor covariant BTW), so without extension dedicated to the common concrete ImmutableList<T> type, user would have to specify the type of T.

In fact they could all be named Create as their overloads defer.

Yes but as lot of theme have delegate as parameter, reducing the number of possible overloads greatly helps type inference for auto-completion.

There are other inconsistensies between the 4 factory classes, for example some don't provide a Func<CancellationToken, ... overload

The overloads that has a CancellationToken are only for those which returns a IAsyncEnumerable to be used with the EnumeratorCancellation so we can use method-group as parameter (And BTW I noticed that one is missing, we should fix it).

instance Update and UpdateAsync can be both named just Update as they're different overloads

Same, reducing the number of overloads to help type-inference and make it clearer to the user what he has to do.

[weitzhandler]

Thanks for your detailed replies @dr1rrb!

So only left with two issues:

• There's one method missing cancellation.
• Some (IListState) some methods have Async suffix while others don't.