[
https://issues.apache.org/jira/browse/METRON-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417257#comment-15417257
]
ASF GitHub Bot commented on METRON-362:
---------------------------------------
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/207
@nickwallen There is still a PredicateProcessor because having a stellar
function which acts as a predicate is a sensible differentiation from a stellar
function which returns an arbitrary function. Just as there is a
java.util.function.Function and a java.util.function.Predicate and they are
distinct. They both reuse a base class, however.
> Unify the stellar languages
> ---------------------------
>
> Key: METRON-362
> URL: https://issues.apache.org/jira/browse/METRON-362
> Project: Metron
> Issue Type: Improvement
> Affects Versions: 0.2.1BETA
> Reporter: Casey Stella
> Assignee: Casey Stella
> Fix For: 0.2.1BETA
>
>
> At the moment, stellar has some architectural issues:
> * The query and transformation languages are distinct despite sharing the
> same transformation functions
> * The transformation language does not have any notion of the comparison
> operations or the logical (aka boolean) functions from the query language
> * Neither language has the ability to do arithmetic or even represent
> negative numbers as constants
> * Neither language has the ability to do simple if/then/else constructs
> We should unify the languages and correct the deficiencies as they have come
> up in multiple situations. This should be done in a backwards compatible way
> so that deployed stellar statements as part of field transformations or
> threat triage do not have to change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
