[ 
https://issues.apache.org/jira/browse/CALCITE-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16576800#comment-16576800
 ] 

Vladimir Sitnikov commented on CALCITE-2462:
--------------------------------------------

https://github.com/apache/calcite/pull/788 is ready.

It is basically a set of existing factory methods from RexProgramTest plus a 
couple of new "call" methods.

New methods:
1) literals. For instance: literal(42), literal("A"), literal((String)null) and 
so on
2) factories for types. For instance: tVarchar(), tInt(), nullable(tInt()), etc.
3) variables from dynamic params instead of "input refs". Input refs are 
printed as $0, $1 and it is hard to understand the type of that $0 (is it 
nullable or not?). The variables can be created as {{vInt(2)}}, and it would be 
printed as {{0?.int2}}

I have not updated existing code in {{RexProgramTest}} (to avoid introducing 
unexpected errors). 

I have added checkSimplifyDynamicParam test that duplicates 
testSimplifyIsNotNull. The improvement there is 18 lines -> 8 lines, and it 
becomes much easier to follow which variables are nullable and which are not 
(even in test output).



I have not created javadoc for all the factory methods since I assume the 
method are obvious, and javadoc would just make the class bigger and harder to 
see what is in there.



> RexProgramTest: move "rex building" methods to base class
> ---------------------------------------------------------
>
>                 Key: CALCITE-2462
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2462
>             Project: Calcite
>          Issue Type: Sub-task
>          Components: core
>    Affects Versions: 1.17.0
>            Reporter: Vladimir Sitnikov
>            Assignee: Julian Hyde
>            Priority: Major
>
> RexProgramTest is quite big (2000 lines now), and "easy to use" rex building 
> is useful for many tests.
> So I suggest to move methods like {{gt}}, {{lt}}, etc to the base class, so 
> multiple other tests can reuse it.
> Alternative option would be to use Kotlin for builders, yet I think Java 
> tests will be there for quite a while, so it would be nice to simplify them 
> as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to