> On 07 Aug 2016, at 22:24, José Valim <[email protected]> wrote: > > Thank you for starting this discussion, Michał. I feel, however, including > examples of code that could be improved by this proposal would strongly > benefit the discussion. I would also like to hear a fair assessment of the > downsides of such feature. A couple come to mind but I won't release > spoilers. :)
Code example is tricky in here, because given the type already provides a compare/2 function it wouldn’t change much, i.e. Ecto.DateTime.compare(starts_at, ends_at) would turn into compare(starts_at, ends_at). Not a big difference. The biggest difference is discoverability of that function and making it standard across all various types. As to downsides, there are some limitations. The biggest one is probably the fact that protocols dispatch based on just the first argument - ideally we would have a multimethod dispatching on both types - this is not available in Elixir right now (and probably it never will be). So the issue is with comparing different types. compare(Decimal.new(1), 1) would work correctly, but compare(1, Decimal.new(1)) wouldn’t. That’s why I said I would be mostly inclined to allowing this function working only across the same type. Another issue is that this function would require some work to adapt for Enum.sort/2. The function in sort is expected to return true if arguments are in the right order, a stable implementation with compare would look like this: Enum.sort(list, &(compare(&1, &2) in [:lt, :eq])), which is a bit of a mouthful. Finally the function wouldn’t work in guards, but that’s true of most of custom functions that are lacking natively in BEAM. > On 07 Aug 2016, at 22:25, Peter Hamilton <[email protected]> wrote: > > Is there any requirement for Comparable to be in elixir core? Could this be > implemented as a library? > Yes. I see big benefit for that function with native calendar types that ship with elixir. Including it in core makes sense in that regard. Furthermore, standalone protocols are a mildly bad idea. We already experience some pains with that in regards to the decimal library and poison. Neither one depends on the other and there’s no canonical Poison.Encoder implementation for Decimal. Ecto has it’s own implementation and that’s mostly fine, but there are some libraries that use decimal and poison and doesn’t depend on Ecto - they define their own implementation of the protocol. This leads to issues with duplicate modules when you use such a library and ecto in the same project. 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/70019F09-3148-4031-8DFF-E674571A7F24%40muskala.eu. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Message signed with OpenPGP using GPGMail
