Hello Jose, I completely understand where you are coming from.
The main reason to add this to the core language is to standardize the return format of comparison functions. I believe this to be a very important idea. *Upcasting* as in the case of Decimals can be supported using the coercion-mechanism explained earlier (and already implemented in the Numbers library: https://github.com/Qqwy/elixir_number/). *Downcasting* as in the case of the (Naive)(Date)(Time) modules on the other hand is something that should happen explicitly in my opionion. Therefore, this feels like a feature that should not be supported on a protocol. Instead, I'd propose to keep the (Naive)(Date)(Tiime).compare functions for that purpose. Again, the main important reason is to standardize the return type of the comparison functions. If this is standardized, it becomes possible to write libraries that can build on top of it. Some ideas: - An ExUnit add-on library that adds assertions like `assert_smaller`, `assert_not_equal` etc. - Alternative container data structures that provide functionality based on the logical ordering of data structures (rather than the Erlang Term Ordering), such as priority queues that do not care if the priority is provided as a Decimal or a DateTime. Right now, building those kinds of things is plain impossible, because you would need to handle the five different types of return values of `SomeModule.compare/2`. Another benefit I see is that programmers would not need to guess what kind of return value a comparison function has. Yesterday I spent half an hour debugging why a list of timestamps was not split at the correct location. Turns out I was doing `Timex.compare == :lt` whereas it should have been `Timex.compare == -1`, which is the kind of implicit implementation behaviour I'd like to not need to think about all the time as a programmer. I do not feel that the comparison with Decimal makes a lot of sense, since this proposal is a lot smaller. Also, `compare/2` and `Comparable.compare/2` will integrate in the language quite a lot, since they will work for built-in types, expecting the two operands to be of the same type( both numbers, both lists, both binaries, both the same kind of struct, etc.). Please standardize the way comparisons are made in the language. It is a very small addition but it will ensure that libraries are consistent in their APIs, allowing new libraries to flourish on top. ~Wiebe-Marten/Qqwy On Friday, June 16, 2017 at 11:23:26 PM UTC+2, José Valim wrote: > > Hi Wiebe-Marten Wijnja, > > Thanks for the well-written proposal. > > I am afraid my opinion has not changed much from the first time around. > The proposed solution would not support the "downcasting" done in > `Date.compare`. `Decimal` may also want to perform casting as well. > And while I understand why it cannot support that and I would take the > same decision as you, it makes it less appealing as we would still need a > custom function in those cases. > And it may also be that those are actually better solved with a specific > compare protocol, such as RataDieCompare or NumberCompare and not a general > purpose one. > > So I believe those protocols should be developed as a separate package and > not included in Elixir. > I do understand the benefits of including it in Elixir itself but to me > the conceptual cost of the new abstraction / mechanism outweighs the gains > in this case. > > I believe I have mentioned in the past the Decimal library is currently on > the same situation. > It is very useful but, unless it is meant to integrate into the language > in a more meaningful way, it will do just fine as a separate package. > > -- 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/3846a7fa-083a-432a-8616-f643ea0816a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
