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/03/10 23:15:04 UTC

[jira] [Created] (EDGENT-393) Wish for Functions.not()

Dale LaBossiere created EDGENT-393:
--------------------------------------

             Summary: Wish for Functions.not()
                 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.3.15#6346)