OHLC should implement IComparable

Hello,

Im just saving your OHLC to Entity framework with Sqllight Core and when im trying to make queries using linkq i got this :

Property ‘HistoricRates.OhlcItem’ cannot be used as a key because it has type ‘OHLC’ which does not implement ‘IComparable<T>’, ‘IComparable’ or ‘IStructuralComparable’. Use ‘HasConversion’ in ‘OnModelCreating’ to wrap ‘OHLC’ with a type that can be compared.’

public static List<OHLC> GetOhlcList(string cryptoCoinName, Granularity granularity)
{
     using (SqliteDbContext dbContext = new SqliteDbContext())
     {

      var c =  dbContext.HistoricRates.Where(s => s.MarketItemName == MarketItemName )     // Multiple market products
                                                    .Where(s => s.GranularityItem == granularity)                   // Multiple timeSpan  5 min 1 hour etc
                                                    .Select(s => new
                                                    {
                                                         s = s.OhlcItem
                                                    }).ToList();
     }
}


public class HistoricRates
{
        public string MarketItemName { get; set; }
        public Granularity GranularityItem { get; set; }
        public OHLC OhlcItem { get; set; }
}

Would be cool if OHLC had IComparable<T> interface !

If you have better idea on how to implement that im open to new ideas ! 😃

[swharden]

I think that just makes it more ambiguous what the comparison does.

I now am unsure that this feature is a good choice.

Especially when a wrapper class with behavior of the user’s choosing is trivially implemented

After thinking about it some more, I feel the same way. To me it doesn’t make intuitive sense to sort or compare candles anyway! Adding extra code just to support an external frameworks is probably not a pattern we want to get into the habit of adopting 😅

[bclehmann]

I agree DateTime may make more sense as the field to compare, but unfortunately I think that just makes it more ambiguous what the comparison does. I now am unsure that this feature is a good choice. If we stored individual points of a scatterplot as a Point struct it would be the same issue, in certain contexts it makes more sense to compare on the x or y value but in general it just adds more confusion.

I’m of the opinion that a feature shouldn’t be added if its behaviour (as interpreted by the user, not the compiler or runtime) is ambiguous. Especially when a wrapper class with behaviour of the user’s choosing is trivially implemented.