apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chinmay Kolhatkar <chin...@datatorrent.com>
Subject Re: APEXCORE-1972: ExpressionEvaluator - quasi-Java Expression Language
Date Thu, 14 Jan 2016 07:34:18 GMT
Hi tim,

I agree with you. The expression here we're talking about is really a
quasi-Java expression. One can do anything which java does.
Only change with java syntax here is how variables are accessed.

They're by default accessed as ${...}.

But this is also made configurable via a setter property on
ExpressionEvaluator. The pull request has it.

If this is what you're talking about then this is taken care of.

Thanks,
Chinmay.


On Thu, Jan 14, 2016 at 1:00 PM, Timothy Farkas <tim@datatorrent.com> wrote:

> Hi Chinmay,
>
> I think this is a very good first implementation. My only concern is that
> people will get caught up in the details of the syntax for this expression
> language. I think a way to avoid that is to make the syntax pluggable. For
> example is there an interface for expression evaluation which can be
> implemented by different syntaxes? This would allow operators which use
> expression evaluation to have the syntax configured via a property. That
> way if someone discovers a limitation in the syntax down the line, a new
> syntax can be introduced without breaking backwards compatibility and
> without requiring operator code to be changed.
>
> Thanks,
> Tim
>
> On Wed, Jan 13, 2016 at 10:52 PM, Chinmay Kolhatkar <
> chinmay@datatorrent.com
> > wrote:
>
> > Hi All,
> >
> > I'm working on APEXCORE-1972 which adds support for a quasi-Java
> Expression
> > Language and its expression evaluator.
> >
> > All the detailed functionality and design details along with examples are
> > present in Jira.
> >
> > I've summarized the ExpressionEvaluator feature & Expression language
> > below.
> >
> > The pull request created for this at here:
> > https://github.com/apache/incubator-apex-malhar/pull/170
> >
> > Please share your thought on this.
> >
> > Thanks,
> > Chinmay.
> >
> >
> > *Summary of functionality of ExpressionEvaluator:*
> >
> >    1. Support quasi-Java Expression which defines a single line
> executable
> >    expression
> >    2. Support for quasi-Java expression based function code, which will
> be
> >    compiled on the fly and made available for execution.
> >    3. Should support accessing multiple fields from multiples input POJOs
> >    while addressing the conversion of private variables to public getter
> >    method for all levels.
> >    4. Should support nested field support
> >    5. quasi-Java expressions should support operands to be mentioned in
> >    following ways:
> >       - ${input.fieldName}
> >          - Access fieldName via a object name.
> >       - ${fieldName}
> >          - Accessing fieldName directly when a single object is
> registered
> >          for operation.
> >       - ${input}
> >          - Accessing object variable directly
> >       - ${input.fieldName.internalField}
> >          - Accessing nested fields
> >       6. There should be some predefined function provided to expression
> >    writer which one can directly use in expression for invoking certain
> >    functionality.
> >    7. These are simple String based, Date time based etc functions.
> >    8. On-need-basic one should be able to easily update Expression
> >    Evaluator to easily add new predefined functions to be made available
> > for
> >    expression writer.
> >    9. User of ExpressionEvaluator should be able to add a custom method
> >    externally to be made available to in expression.
> >    10. Though operands are defined, placeholder for the operand in
> >    expression should be allowed to be overridden. By default, expression
> >    language should support bash type syntax for operand - {…}
> >    11. The library should not introduce any serialization related issues.
> >    12. All the java operators should be supported.
> >
> > ​
> >
> > *The examples of quasi-Java Expression:*
> >
> >    - ${inp.field1}
> >       - Will return value of field1 from registered input POJO.
> >    - ${inp.field1} + ${inp.field2}
> >       - Will return sum of field1 & field2 from given POJO
> >    - ${field1} + ${field2}
> >       - Equivalent to above
> >    - ${inpA.field1} > ${inpA.field2} ? ${inpA.field3} : ${inpB.field3}
> >       - Executes ternary expression and returns value accordingly. Works
> on
> >       2 POJOs. inpA & inpB are two placeholder registered for given POJO
> > with
> >       ExpressionEvaluator library.
> >    - pow(${inpA.field1}, ${inpB.field2})
> >       - Executes pow function coming from java.lang.Math library. This
> and
> >       other with lot other basic functions is available to expression
> > writer out
> >       of the box to use in expression.
> >    - ${inpA.field1} > 0 ? ${inpB.innerPOJO.field3} :
> >    ${inpA.innerPOJO.field3}
> >       - Shows how nested POJOs can be accessed in expression. The
> variables
> >       will evaluate to correct public getter method is required.
> >    - ${inp.firstname} + “ “ + ${inp.lastname}
> >       - Generate the full name as per given expression from firstname and
> >       lastname field.
> >    - long retVal=1; for (int i=0; ${inpF.value1}; i++) {retVal = retVal *
> >    ${inpF.value1}; } return retVal;
> >       - This tells a complete method content to ExpressionEvaluator. The
> >       library create an executable and compiled method using this
> > expression.
> >
> > ​
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message