[
https://issues.apache.org/jira/browse/EDGENT-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240903#comment-16240903
]
Dale LaBossiere commented on EDGENT-393:
----------------------------------------
Upon further thinking I'm less ready to commit to asking for / adding
Functions.not().
Instead I'm changing this JIRA to ask for a Range specific enhancement
to accomplish the same effect: Ranges.outsideOf().
Used like:
{code}
TStream ...
.filter(Ranges.outsideOf(Ranges.closed(100,200))) // true if outside
[100..200]
{code}
> Wish for Ranges.outsideOf()
> ---------------------------
>
> Key: EDGENT-393
> URL: https://issues.apache.org/jira/browse/EDGENT-393
> Project: Edgent
> Issue Type: Wish
> Components: API
> Reporter: Dale LaBossiere
> Priority: Minor
>
> I want to be able to write something like:
> {code}
> TStream ...
> .filter(Functions.not(Ranges.closed(100,200))) // true if outside
> [100..200]
> {code}
> The above creates only a single Range and single "not" predicate at topology
> construction time.
> If I made the following mistake I'd create a Range for every tuple:
> {code}
> TStream ...
> .filter(t -> ! Ranges.closed(100,200).contains(t))
> {code}
> In the absence of a "not" Predicate like approach I'd have to explicitly
> allocate my range outside of the lambda:
> {code}
> Range myRange = Ranges.closed(100,200);
> TStream ...
> .filter(t -> ! myRange.contains(t))
> {code}
> The implementation of "not" is trivial and seems like it might be useful in
> other cases:
> {code}
> static <T> Predicate<T> not(Predicate<T> predicate) {
> return t -> ! predicate.test(t);
> }
> {code}
> Yes, I'd be trading off an additional {{Predicate.test()}} invocation per
> tuple against the "out of line" myRange instantiation approach. But I'd get
> to choose which was more important to me.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
