The documentation for not-after? recites:
Like before?, except returns true if the inputs are equal.
The documentation for before? states:
Returns true if time entities are ordered from the earliest to the latest (same semantics as <), otherwise false.
This seems to imply that not-after? should be semantically equivalent to <=, but it is not when invoked like:
If semantically equivalent, this s-expression should have returned true. Note that before? is, in fact, semantically equivalent to <:
This issue seems to be a consequence of how not-after? is defined as the complement of after?, as the latter is consistent with the behavior of >:
The same applies to not-before?.
Not sure if this is intended behavior or not, but I found it rather confusing. In addition, when one of these functions is apply-ed, the client code is forced to explicitly check for the arity 1 case and override the result of the evaluation, like so:
(if (> (count coll) 1)
(apply not-after? coll)
true)
The documentation for
not-after?recites:The documentation for
before?states:This seems to imply that
not-after?should be semantically equivalent to<=, but it is not when invoked like:If semantically equivalent, this s-expression should have returned
true. Note thatbefore?is, in fact, semantically equivalent to<:This issue seems to be a consequence of how
not-after?is defined as the complement ofafter?, as the latter is consistent with the behavior of>:The same applies to
not-before?.Not sure if this is intended behavior or not, but I found it rather confusing. In addition, when one of these functions is
apply-ed, the client code is forced to explicitly check for the arity 1 case and override the result of the evaluation, like so: