Hi Vlad,

Please find the answers inline.

Thanks,
Chinmay.


On Mon, Jan 18, 2016 at 1:26 AM, Vlad Rozov <[email protected]> wrote:

> I have few concerns regarding the proposal, so my vote is -0 till they are
> resolved
>
> 1. Usage of quasi-Java proprietary language. Even though most of the
> syntax adheres to Java, usage of ${} invalidates ability to use general
> IDEs to develop expressions. Debugging and verifying correctness of any
> complex expression becomes a non trivial task for application developers.
>
   [CK] ${} is used so as to identify the operands and replace it when
correct variables/getter methods. Though, the interface is created in such
a way that one can override this. So top level interfaces are:
    Expression - Object of executable expression.
    ExpressionParser - One which parses expression.  Comcrete example is
JavaExpressionParser
    ExpressionEvaluator - One which converts parsed expression into an
executable expression. ExpressionParser goes as a plugin to
ExpressionEvaluator. Concrete impl is JavaExpressionEvaluator.

   Because of this interface one is free to override the parsing and
evaluation logic.
   Also JavaExpressionParser has a setter method using which one can
override the regex for ${}.

2. What other languages were considered for expressions? Why quasi-Java was
> selected in favor of for example SQL syntax?
>
  [CK] The aim of choosing quasi-Java language is to provide and complete
functionality as well as performance.
    As per the interface defined above, one can very well chose to override
the ExpressionParser and ExpressionEvalator to even have a SQL based
implementation for expression.


> 3. Separating imports from expressions seems as inconvenience to
> expression developers to me. Why imports can't be specified as part of
> expression definition?
>
  [CK] The purpose of imports is to have some public static method to be
part of expression. For eg. java.util.Math.* is statically imported by
default. This gives expression writer a freedom to use the static methods
present in java.util.Math  out of the box in expression.
     One can very well chose to have imports in expression itself.
     For eg. Following is a valid expression and respective import in
expression will also be considered:

     import org.apache.x.y.z;
     <expression>

4. Where multiple POJOs come from? If assumption is that different POJOs
> come from different input ports, how tuples from different ports are
> synchronized?
>
  [CK] Honestly, I don't have a usecase where multiple POJOs will become
part of a single expression. I've done this for a purpose of completion of
expression language. Of course, I would love to get some feedback from
community if there is a possible usecase for this.


> 5. Are we supporting both POJOUtils and ExpressionEvaluator? If not, what
> is the plan to deprecate POJOUtils? If yes, syntax of POJOUtils and
> ExpressionEvaluator don't seem to be compatible.
>
  [CK] I haven't though about PojoUtils deprecation yet. In my opinion, it
should not be done. PojoUtils has its own purpose. It deals with POJOs and
simple operation which require faster interface to access variables from
POJO. If that is the usecase one should use PojoUtils. ExpressionEvaluator
is to support expression based execution.
   But I'm open to thoughts here.
   About incompatibility, we can make it compatible. Can you please share
where it is different? Is it the operand syntax you're talking about ${} of
Expression vs {}  of PojoUtils. I'll happy to make Expression to be
compatible with PojoUtils for the same.

6. POJOUtils supports both getters and setters, what is the plan to support
> setters in ExpressionEvaluator?
>
  [CK]  I'm not sure functionality of ExpressionEvalutor can be encompassed
within getter/setter. ExpressionEvaluator lets one execute a given
expression and provide a value returned by Expression.


> Thank you,
>
> Vlad
>
> On 1/13/16 22:52, Chinmay Kolhatkar 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.
>>
>> ​
>>
>>
>

Reply via email to