> DateTime.compare(a, :<, b) would get my vote of the alternative proposals but I think it doesn't move much the needle in comparison to DateTime.compare.
To me this is a pretty big difference difference, because with an `import` it does 2 things: 1) Eliminates the existence of an irrelevant, boilerplate operator == 2) positions the 2 values you care about correctly with respect to the relevant operator When you have DateTime.compare(a, b) == :lt it's like RPN, you have to hold a and b in your head, remember their order, then skip past the `==` since it doesn't matter, and finally you get to see your comparison. When discussing this in complex contexts the need to try to distinguish about whether you're talking about what the _function call is equal to_ from whether the values themselves are equal to is actually a pretty big deal. There are basically 4 characters with semantic value, and there rest are boilerplate. When you have a bunch of these all next to each other (like when building up complex range helpers) https://gist.github.com/benwilson512/456735775028c2da5bd38572d25b7813 it's just a ton of data to filter out. If you could `import DateTime, compare?: 3` this could be compare?(a, :<, b) compare?(a, :<=, b) On Monday, October 31, 2022 at 2:02:03 PM UTC-4 Cliff wrote: > > in Elixir the subject is always the first argument > > Ah, that clears it up for me, I hadn't yet realized that symmetry in the > APIs. I like the before?/after? functions now. > > On Monday, October 31, 2022 at 1:16:52 PM UTC-4 José Valim wrote: > >> I am not worried about the argument order because in Elixir the subject >> is always the first argument. So it is always "is date1 before date2?". I >> like the :inclusive option if the need ever arises. >> >> DateTime.compare(a, :<, b) would get my vote of the alternative proposals >> but I think it doesn't move much the needle in comparison to >> DateTime.compare. >> >> On Mon, Oct 31, 2022 at 5:44 PM Cliff <notcliff...@gmail.com> wrote: >> >>> I would prefer the atoms *:before*, and *:after* rather than >>> :gt/:greater_than/etc. Since we're already solving the problem of >>> operator/argument ordering, why not remove the final mental barrier of >>> reasoning about whether a time being "greater than" another time means that >>> it is before or after? *foo(a, :gt, b)* still requires a second thought >>> ("Is a bigger time earlier or later?"), whereas if I read code that said >>> *foo(a, >>> :before, b)* I would feel confident in my understanding after only the >>> first read. >>> >>> On Monday, October 31, 2022 at 12:35:05 PM UTC-4 lui...@gmail.com wrote: >>> >>>> I also prefer something like *DateTime.compare(a, operator, b)*. >>>> >>>> Operators don't need to be *cryptic* like *:eq*, *:gt*, *:lte*, etc., >>>> we can use the same comparison operators we already are used to: >>>> >>>> *DateTime.compare(a, :<, b)* >>>> *DateTime.compare(a, :==, b)* >>>> *DateTime.compare(a, :>=, b)* >>>> >>>> It's clear and much less verbose than the Ecto's (which was a great >>>> suggestion, by the way). >>>> >>>> On Monday, October 31, 2022 at 5:23:54 PM UTC+1 and...@dryga.com wrote: >>>> >>>>> Hey guys, as an idea why don't we reuse atoms from Ecto: >>>>> >>>>> - :less_than >>>>> - :greater_than >>>>> - :less_than_or_equal_to >>>>> - :greater_than_or_equal_to >>>>> - :equal_to >>>>> - :not_equal_to >>>>> >>>>> I feel like they are fairly common nowadays and even though it's more >>>>> to type make it easier to understand when you want an inclusive >>>>> comparison. >>>>> >>>>> We can later make it part of all modules that have `compare/2` (Date, >>>>> DateTime, Time, Version, etc). >>>>> >>>>> On Monday, October 31, 2022 at 10:10:09 AM UTC-6 Cliff wrote: >>>>> >>>>>> I prefer the form *DateTime.is(a, operator, b)*, but I agree with >>>>>> others that it would need a more sensible name than "is". >>>>>> >>>>>> Regarding the form *DateTime.before?(a, b)*, I could still see >>>>>> myself getting confused by argument order. *before?(a, b)* might be >>>>>> read as "before A happened, B happened", rather than the intended "A >>>>>> happened before B". the *is(a, :before, b)* form, however, is read >>>>>> exactly how it would be spoken. >>>>>> >>>>>> Regarding comparison inclusivity, another possibility is a keyword >>>>>> option: *DateTime.before?(a, b, inclusive: true)* >>>>>> >>>>>> On Monday, October 31, 2022 at 3:45:15 AM UTC-4 simonmc...@gmail.com >>>>>> wrote: >>>>>> >>>>>>> DateTime.before?(a, b) is much nicer than DateTime.compare(a, b) == >>>>>>> :lt. It doesn't completely remove the argument order issue but I >>>>>>> reckon it >>>>>>> would resolve it for me. I run DateTime.compare(a, b) in iex every >>>>>>> time I >>>>>>> use the function because I'm terribly forgetful and paranoid. I would >>>>>>> prefer DateTime.eq?/lt?/le?/gt?/ge? instead of >>>>>>> before?/after?/on_or_before?/on_or_after? which is shorter, matches >>>>>>> compare/2 and might allow the le/ge equivalents to sneak through. I >>>>>>> think >>>>>>> it would be a shame to leave out le and ge. >>>>>>> >>>>>>> DateTime.is?/compare?(a, :lt, b) is a whole lot less ambiguous to >>>>>>> me. It reads how you would write it in maths or spoken language. >>>>>>> >>>>>>> On Monday, 31 October 2022 at 5:08:35 pm UTC+10 >>>>>>> zachary....@gmail.com wrote: >>>>>>> >>>>>>>> I wonder how much of the issue is the Api and how much of the issue >>>>>>>> is just the docs? I.e its not a given that all arguments in every >>>>>>>> position >>>>>>>> always make sense, but we typically rely on things like elixir_ls to >>>>>>>> help >>>>>>>> us when the answer isn't obvious. >>>>>>>> >>>>>>>> Could we perhaps just improve the docs in some way? i.e update the >>>>>>>> specs to say `datetime :: Calendar.datetime(), compares_to :: >>>>>>>> Calendar.datetime()`, and have the args say `compare(datetime, >>>>>>>> compares_to)` and have part of the first line of text say something a >>>>>>>> bit >>>>>>>> more informative? >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Oct 31, 2022 at 3:02 AM, Jon Rowe <ma...@jonrowe.co.uk> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I'm not sure the name is right, but I like >>>>>>>>> >>>>>>>>> DateTime.is?(a <http://datetime.is/?(a>, operator, b), when >>>>>>>>> operator :lt | :le | :eq | :ge | :gt, which would capture the :le and >>>>>>>>> :ge >>>>>>>>> options. >>>>>>>>> >>>>>>>>> >>>>>>>>> As a usage api, we could actually have `compare?/3` especially as >>>>>>>>> the name doesn't overlap with `compare/2` which would hopefully >>>>>>>>> alleviate >>>>>>>>> anyones concerns about the return type changing >>>>>>>>> >>>>>>>>> On Mon, 31 Oct 2022, at 6:23 AM, José Valim wrote: >>>>>>>>> >>>>>>>> My thought process is that a simple to use API should be the focus, >>>>>>>>> because we already have a complete API in Date.compare/2 >>>>>>>>> <http://date.compare/2> and friends. >>>>>>>>> >>>>>>>>> On Mon, Oct 31, 2022 at 02:16 Simon McConnell < >>>>>>>>> simonmc...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> would we want on_or_after? and on_or_before? as well then? Or >>>>>>>>> something like DateTime.is?(a <http://datetime.is/?(a>, operator, >>>>>>>>> b), when operator :lt | :le | :eq | :ge | :gt, which would capture >>>>>>>>> the :le >>>>>>>>> and :ge options. >>>>>>>>> >>>>>>>>> On Monday, 31 October 2022 at 7:26:42 am UTC+10 José Valim wrote: >>>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> >>>>>>>>> A PR that adds before?/after? to Time, Date, NaiveDateTime, and >>>>>>>>> DateTime is welcome! >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sun, Oct 30, 2022 at 6:46 PM Cliff <notcliff...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I did a bit of research. Many other languages use some form of >>>>>>>>> operator overloading to do datetime comparison. The ones that do >>>>>>>>> something >>>>>>>>> different: >>>>>>>>> >>>>>>>>> - Java has LocalDateTime.compareTo(other) >>>>>>>>> >>>>>>>>> <https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/LocalDateTime.html#compareTo(java.time.chrono.ChronoLocalDateTime)>, >>>>>>>>> >>>>>>>>> returning an integer representing gt/lt/eq. There is also >>>>>>>>> LocalDateTime.isBefore(other) >>>>>>>>> >>>>>>>>> <https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/LocalDateTime.html#isBefore(java.time.chrono.ChronoLocalDateTime)>, >>>>>>>>> >>>>>>>>> LocalDateTime.isAfter(other), and LocalDateTime.isEqual(other). >>>>>>>>> The >>>>>>>>> LocalDateTime.is <http://localdatetime.is/>{Before, After} >>>>>>>>> methods are non-inclusive (<, >) comparisons. They are instance >>>>>>>>> methods, so >>>>>>>>> usage is like `myTime1.isBefore(myTime2)` >>>>>>>>> - OCaml's "calendar" library provides a Date.compare >>>>>>>>> >>>>>>>>> <https://ocaml.org/p/calendar/3.0.0/doc/CalendarLib/Date/index.html#val-compare> >>>>>>>>> >>>>>>>>> function that returns an integer representing gt/lt/eq (for use in >>>>>>>>> OCaml's >>>>>>>>> List.sort function, which sorts a list according to the provided >>>>>>>>> comparison >>>>>>>>> function). It also provides Date.> >>>>>>>>> >>>>>>>>> <https://ocaml.org/p/calendar/3.0.0/doc/CalendarLib/Date/index.html#val-(%3E)>, >>>>>>>>> >>>>>>>>> and Date.>= >>>>>>>>> >>>>>>>>> <https://ocaml.org/p/calendar/3.0.0/doc/CalendarLib/Date/index.html#val-(%3E=)>, >>>>>>>>> >>>>>>>>> etc. Worth noting is that OCaml allows you to do expression-level >>>>>>>>> module >>>>>>>>> imports, like *Date.(my_t1 > my_t2)* to use Date's *>* >>>>>>>>> function in the parenthesized expression without needing to *open >>>>>>>>> Date* in the entire scope ("open" is OCaml's "import") - this >>>>>>>>> could potentially be possible in Elixir using a macro? >>>>>>>>> - Golang: t1.After(t2) <https://pkg.go.dev/time#Time.After>, >>>>>>>>> t1.Before(t2), t1.Equal(t2). Non-inclusive (> and <). >>>>>>>>> - Clojure clj-time library: (after? t1 t2) >>>>>>>>> >>>>>>>>> <https://clj-time.github.io/clj-time/doc/clj-time.core.html#var-after.3F>, >>>>>>>>> >>>>>>>>> (before? t1 t2) >>>>>>>>> >>>>>>>>> <https://clj-time.github.io/clj-time/doc/clj-time.core.html#var-before.3F>, >>>>>>>>> >>>>>>>>> and (equal? t1 t2) >>>>>>>>> >>>>>>>>> <https://clj-time.github.io/clj-time/doc/clj-time.core.html#var-equal.3F>. >>>>>>>>> >>>>>>>>> IMO the argument order is still confusing in these. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sunday, October 30, 2022 at 3:15:14 AM UTC-4 José Valim wrote: >>>>>>>>> >>>>>>>>> I am definitely in favor of clearer APIs. >>>>>>>>> >>>>>>>>> However, it would probably be best to explore how different >>>>>>>>> libraries in different languages tackle this. Can you please explore >>>>>>>>> this? >>>>>>>>> In particular, I am curious to know if before/after mean "<" and ">" >>>>>>>>> respectively or if they mean "<=" and "=>" (I assume the former). And >>>>>>>>> also >>>>>>>>> if some libraries feel compelled to expose functions such as >>>>>>>>> "after_or_equal" or if users would have to write Date.equal?(date1, >>>>>>>>> date2) >>>>>>>>> or Date.earlier?(date1, date2), which would end-up doing the double >>>>>>>>> of >>>>>>>>> conversions. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 elixir-lang-co...@googlegroups.com. >>>>>>>>> >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/fcd07389-c6a0-497d-9c09-7f1eacf620c6n%40googlegroups.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/fcd07389-c6a0-497d-9c09-7f1eacf620c6n%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 elixir-lang-co...@googlegroups.com. >>>>>>>>> >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/e6c55604-c3ea-464c-908c-5a6092f4d8edn%40googlegroups.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/e6c55604-c3ea-464c-908c-5a6092f4d8edn%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 elixir-lang-co...@googlegroups.com. >>>>>>>>> >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2ByT9jA7uqGX0Cyapgfx0AjW%2BU_d4Ai-NQ6vD9UsEb2uQ%40mail.gmail.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2ByT9jA7uqGX0Cyapgfx0AjW%2BU_d4Ai-NQ6vD9UsEb2uQ%40mail.gmail.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 elixir-lang-co...@googlegroups.com. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/2e821e87-6ee0-4702-b69f-e2616b61b1dd%40app.fastmail.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/2e821e87-6ee0-4702-b69f-e2616b61b1dd%40app.fastmail.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 elixir-lang-co...@googlegroups.com. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/7435b979-d0eb-4726-aa65-a94ada53d320n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/elixir-lang-core/7435b979-d0eb-4726-aa65-a94ada53d320n%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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/c7248c40-daf0-4db2-9511-0b730cc711e2n%40googlegroups.com.
