edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dale LaBossiere (JIRA)" <j...@apache.org>
Subject [jira] [Assigned] (EDGENT-393) Wish for Ranges.outsideOf()
Date Mon, 06 Nov 2017 21:10:00 GMT

     [ 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)

Mime
View raw message