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-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/902e971f-62ec-41ac-93cc-d6bcbad1446cn%40googlegroups.com.
