Two days ago I talked with OverminDL1 because I had trouble to understand exactly what his implementation was trying to do. Now I understand, and I find it a very interesting idea. It would solve the 'too many modules' problem. (Although I still don't know why this is a problem). It would also dispatch faster, because no dynamic dispatching during calls to `compare?` would be necessary.
His idea is basically to recompile the `Compare` module every time a new comparison is defined, by taking its old AST (which could be provided by a function on the current compiled Compare module), and adding in a new `compare`-clause to handle the new comparison case. This means that most work is performed during the creation of a compare-implementation(of which there probably are relatively few), and subsequent calls to `compare` (of which there probably are many) are thus more efficient. OverminDL1 further had the idea to allow multiple modules with such structure(i.e. extendable in the same way, but filled with different comparison implementations) to exist side-by-side, but I don't think that is something we would need. Maybe if we ever want full-blown multimethod dispatching in Elixir, but not for Comparable. KISS, YAGNI, etc. 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/4cd461a8-f0be-4360-940f-353f23f53368%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
