Nevermind, the Ordered protocol still wouldn't work for Integer/Float/Decimal, as they can't converted to a single ordered/sortable term.
I think a complete proposal would need to contemplate both calendar types and the latest reverse_sort proposal. Stay tuned. *José Valimwww.plataformatec.com.br <http://www.plataformatec.com.br/>Founder and Director of R&D* On Thu, Oct 17, 2019 at 10:53 PM José Valim <[email protected]> wrote: > To clarify, the Ordered protocol would be like this: > > defprotocol Ordered do > def ordered(data) > end > > Basically, it would work like Date.sortable, but implemented with a > protocol so it works across data-types. > > *José Valimwww.plataformatec.com.br > <http://www.plataformatec.com.br/>Founder and Director of R&D* > > > On Thu, Oct 17, 2019 at 10:34 PM José Valim <[email protected]> wrote: > >> I have put more thoughts into this. >> >> If our goal is to have something that can be easily sortable, computed a >> max and a min, etc, then the best option is to introduce a sortable >> function: >> >> sortable(date) :: term() >> >> The goal of this function is to return a sortable term, according to >> Erlang Term Ordering. >> >> Then we can do: >> >> Enum.sort_by(datetimes, &Date.sortable/1) >> Enum.min_by(datetimes, &Date.sortable/1) >> Enum.max_by(datetimes, &Date.sortable/1) >> >> If you want to sort users by their update date: >> >> Enum.sort_by(users, & &1.updated_at |> Date.sortable()) >> Enum.min_by(users, & &1.updated_at |> Date.sortable()) >> Enum.max_by(users, & &1.updated_at |> Date.sortable()) >> >> The only downside of this implementation is that it may not be as >> efficient because we will have to convert to iso days so they are sortable >> across calendars. >> >> === >> >> There is a longer discussion here about introducing a new protocol, >> called Ordered, and an Enum.order/1 function. Then Enum.order(dates) would >> automatically work, because it would dispatch to a protocol which is always >> correct. This is all good on paper but I can foresee two downsides: >> >> 1. We would need to introduce an "Ordered" version of min/max. Perhaps >> something like order_first/order_last or order_min/order_max. >> >> 2. I am not aware of any prior art on this. Most of the >> protocols/typeclasses/interfaces I know for ordering build them based on >> comparisons. Is anyone aware of a reference on the topic? >> >> Thoughts? >> >> -- >> 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/56a992a6-0ae1-4d67-9145-dbee40935bae%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/56a992a6-0ae1-4d67-9145-dbee40935bae%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAGnRm4KfO5%3DZxqmqa%2BWw5HxfQWwGKwcrY4QR-mdcev4QddmiMQ%40mail.gmail.com.
