A situation that I find myself in repeatedly is that I have a OneOf n-types which share some characteristics. They are not the same but they are similar enough.
So I find myself using OneOfBase like:
In some cases I resolve this by using a base class instead of a OneOf to represent the DU. Something like
abstract class Animal
{
public string Name { get; set; }
public abstract T Match<T>(
Func<Racoon, T> racoon,
Func<Fox, T> fox);
}
class Racoon : Animal
{
public T Match<T>(
Func<Racoon, T> racoon,
Func<Fox, T> fox);
{
return racoon(this);
}
}
class Fox : Animal
{
public T Match<T>(
Func<Racoon, T> racoon,
Func<Fox, T> fox);
{
return fox(this);
}
}
However, if other base classes are involved, or the types are not related enough for other reasons, this is not an option.
When using a oneof, I'd write it as:
public class Animal : OneOfBase<Racoon, Fox>
{
public string Name => Match(
x => x.Name,
x => x.Name);
}
Of course it can get significantly more involved with multiple properties / methods. It's not efficient in terms of coding and performance.
So I was thinking we could do something like:
static class AllAre<T>
{
abstract class OneOfBase<T1,T2,T3>
where T1 : T
where T2 : T
where T3 : T
{
T Value { get; } // instead of object. The rest would be the usual OneOf stuff.
}
}
class Animal: AllAre<IAnimal>.OneOf<
Racoon,
Fox>
{
public string Name => Value.Name;
}
Have you ever considered this? Do you see a reason against it?
Of course it could get more complicated, like wanting to have more type constraints like AllAre<IAnimal, IDisposable>.
Specifically I'm asking here not just for "should it be integrated into the OneOf library" but more on a conceptual level. After all, if it isn't integrated into OneOf, it could also be done in a separate library.
Thank you
A situation that I find myself in repeatedly is that I have a OneOf n-types which share some characteristics. They are not the same but they are similar enough.
So I find myself using OneOfBase like:
In some cases I resolve this by using a base class instead of a OneOf to represent the DU. Something like
However, if other base classes are involved, or the types are not related enough for other reasons, this is not an option.
When using a oneof, I'd write it as:
Of course it can get significantly more involved with multiple properties / methods. It's not efficient in terms of coding and performance.
So I was thinking we could do something like:
Have you ever considered this? Do you see a reason against it?
Of course it could get more complicated, like wanting to have more type constraints like
AllAre<IAnimal, IDisposable>.Specifically I'm asking here not just for "should it be integrated into the OneOf library" but more on a conceptual level. After all, if it isn't integrated into
OneOf, it could also be done in a separate library.Thank you