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)