You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@edgent.apache.org by "Dale LaBossiere (JIRA)" <ji...@apache.org> on 2017/11/06 21:10:00 UTC

[jira] [Assigned] (EDGENT-393) Wish for Ranges.outsideOf()

     [ https://issues.apache.org/jira/browse/EDGENT-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dale LaBossiere reassigned EDGENT-393:
--------------------------------------

    Assignee: Dale LaBossiere

> 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
>            Assignee: 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)