> standalone protocols are a mildly bad idea. I'd love for some exploration of solutions to the painpoints of protocols. That may be a separate discussion but it seems like if that's the status quo then protocols need to be revisited. That's not a knock against the current implementation of protocols, but perhaps there's a lesson to be learned and productive changes that can be made in the future.
On Sun, Aug 7, 2016, 3:45 PM Michał Muskała <[email protected]> wrote: > > > 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. > -- 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/CAOMhEnx6E9txxQYddHm64gUsenoYpkOHJ8ttNOHAFOCYOmukRg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
