How to use "DomainType<SELF, REPR>" with complex values

[HernanFAR]

As far as I see, the most ideal use case of DomainType, is for value objects that are only a wrapper around one property, like this:

public sealed class NonEmptyString : DomainType<NonEmptyString, string>
{
    private readonly string _value;

    private NonEmptyString(string value)
    {
        _value = value;
    }

    public override string ToString() => _value;

    public static NonEmptyString From(string repr) =>
        string.IsNullOrEmpty(repr) is false
            ? throw new InvalidOperationException("Value cannot be empty or null")
            : new NonEmptyString(repr);

    public string To() => _value;
}

But, how to we use DomainType with more complex value objects, like this one?

public sealed class OfficeApprover : DomainType<OfficeApprover, (InternalUserId InternalUserId, string TextA, string TextB)>
{
    private OfficeApprover(InternalUserId internalUserId, string textA, string textB)
    {
        InternalUserId = internalUserId;
        TextA = textA;
        TextB = textB;
    }

    public InternalUserId InternalUserId { get; }

    public string TextA { get; }

    public string TextB { get; }


    public static OfficeApprover From((InternalUserId InternalUserId, string TextA, string TextB) value) 
        => new(value.InternalUserId, value.TextA, value.TextB);

    public (InternalUserId InternalUserId, string TextA, string TextB) To() => (InternalUserId, TextA, TextB);
}

[louthy]

Not sure if you've seen it yet, but the blog post that started off the domain-type traits is worth a read; it gives the motivation for the feature.

In my mind, domain-types and their derivatives AmountLike, IdentifierLike, LocusLike, QuantityLike, and VectorSpace are really about strongly-typing primitive-types like int, float, etc. The idea is to support a common set of features depending on the domain-type. So, for a database ID you might use IdentifierLike, for a typed length, you might use VectorSpace, etc.

I don't think it's necessarily wrong to have a domain-type that represents a tuple of values -- for complex numbers, or vectors, it would work well -- but, I think, for types that probably should just be records, it might be taking the idea too far.

Hands up, I haven't thought that far ahead on this feature yet, but instinctively it feels to be stretching the idea. However, from a type-theoretical point-of-view, it's completely legitimate to project a tuple onto a record, they are, after all, both product-types. So, yeah I guess you should consider what you're getting out of doing this, to decide if this is valuable or not.

Big fat NOTE: This feature is extremely underdeveloped right now. Both VectorSpace and QuantityLike are incomplete and the usefulness behind this standardisation of domain-types will probably only be realised when I build additional functionality that works with the various domain-types (and potentially source-generators). But, I don't yet know what that functionality will be, or whether it will actually be useful! So, be aware, this feature might not make it to release, or, the type-names and implementation might be different, or the From might return an Option<SELF>, etc. So, buyer beware right now.