I discussed with Thomas Depierre (@di4na) today about this, and he convinced me that atoms are indeed more explicit than integers, because during debugging something that crashed, instead of seeing 'a number' as result of the comparison function, you see 'a name' which is self-describing.
Instead of going with :lt, :eq and :gt, which do not follow Erlang's term ordering, I came up with using :<, := and :>, which do, and are also the mathematical symbols used when describing inequality. The experimental example implementation <https://github.com/Qqwy/elixir_experimental_comparable> I posted before has been updated to reflect this change. On Sunday, August 7, 2016 at 10:13:45 PM UTC+2, Michał Muskała wrote: > > Hello everybody, > > Today I’d like to address one of annoyances of working with elixir - > comparing structs. It’s a problem because of two reasons: > - it’s not widely known that the regular comparison operators do not work > correctly with structs > - there’s no standard way of providing custom comparison function. > This issue is especially apparent in couple libraries, most notably Ecto > (with calendar types), decimal and with the new standard calendar types. > > I propose adding a Kernel.compare/2 function with signature: > compare(term, term) :: :lt | :eq | :gt > > I would propose following properties of the function: > - inlined implementation for built-in types, only for both arguments of > the same type > - for structs the function calls the Comparable.compare/2 protocol > function > - implementation for structs are allowed to return value for two different > types when it makes sense > - the protocol is also implemented for built-in types > - the protocol does not fallback to Any > > I’m convinced this will allow for much easier experience when comparing > structs, even though the VM does not allow to extend the regular comparison > operators. > > Michał. > > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/14900585-5cd0-4704-a240-23af4f7a5da7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
