By integrating into the language, I mean in a way that it would yield large benefits only if made part of the language. The proposed solution and Decimal yield almost no benefits if part of Elixir compared to as a package, besides reachability.
Also, the current proposal for coerce doesn't handle coercing from struct to struct. If it does, it requires both sides implement the coercion and having an intermediate representation is almost always better. If the goal is to standardize return types, then I think the best is to actually start using them in Elixir itself. We have already started with the calendar types, so others will be able to follow accordingly. On Sat, Jun 17, 2017 at 00:16 Wiebe-Marten Wijnja <[email protected]> wrote: > 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. >> >> -- *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D -- 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/CAGnRm4J61eNV-bcw_V6i9NqgwPZLkNoFiS2cxioP%2BYQTLWF5tA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
