Is it correct from DDD POV to compare ValueObject to different types?

[xavierjohn]

I saw this unit test.

CSharpFunctionalExtensions/CSharpFunctionalExtensions.Tests/ValueObjectTests/IComparableTests.cs

Line 113 in 049db33

public void Can_compare_value_objects_with_different_types()

      public void Can_compare_value_objects_with_different_types()
        {
            var intValueObject = new VOIntType(1);
            var stringValueObject = new VOStringType("2");

            int result1 = intValueObject.CompareTo(stringValueObject);
            int result2 = stringValueObject.CompareTo(intValueObject);

            result1.Should().BeLessOrEqualTo(-1);
            result2.Should().BeGreaterOrEqualTo(-1);
            result1.Should().Be(-result2);
        }

and I was thinking if it is correct to compare ValueObject with primitive types?

When the types are different, ValueObject is doing a string compare.
https://github.com/vkhorikov/CSharpFunctionalExtensions/blob/049db331491e7894361ef9d0640f8375a906eed3/CSharpFunctionalExtensions/ValueObject/ValueObject.cs

            Type thisType = GetUnproxiedType(this);
            Type otherType = GetUnproxiedType(other);
            if (thisType != otherType)
                return string.Compare($"{thisType}", $"{otherType}", StringComparison.Ordinal);

Is that correct?

[powerdude]

That's just against type names in order to get a 1 or -1. so "VOIntType" == "VOStringType" since Compare returns an int.

[xavierjohn]

Is it correct to compare VOIntType to VOStringType?

[xavierjohn]

The other part is

ValueObject : IComparable, IComparable<ValueObject>

Per DDD, ValueObject talks about equality but not comparability. What does IComparable mean to an Address VO?
Should the class be defined as

ValueObject : IEquatable<ValueObject>

and maybe another class

ComparableValueObject : IComparable<ComparableValueObject>, ValueObject 

?

[vkhorikov]

What does IComparable mean to an Address VO?

This is just to be able to sort a collection of VOs using LINQ. Also, I think comparability is directly related to equitability -- if you can check if 2 VOs are equal, then you can also compare them if they aren't.

Is it correct to compare VOIntType to VOStringType?

Initially, the class threw an exception because I though there should be no valid scenarios with VO hierarchies, but I changed that after I found a valid use case for VO inheritance: https://enterprisecraftsmanship.com/posts/hierarchy-value-objects/

[xavierjohn]

I don't have a good solution here but these are the problems.

1. To compare two objects we only need to implement IEquatable

2. Some VO needs sorting like Money so they also need to implement IComparer. Now we force VO of type URI or Address to be comparable which does not make sense, and people have to write fake code to make an Address sort able.
   LINQ does not require IComparable, but IComparable is used by default. OrderBy and OrderByDescending also accept IComparer

3. Using IEnumerable GetEqualityComponents() causes boxing for structs. Using source code generator for simple cases could be a solution here.