Thinking about using the Kotlin operator syntax

[progress0407]

What do you think about using the kotlin operator syntax?

In some cases, but not all, infixes seem to lend themselves to a slightly more intuitive interpretation than prefixes.

vectorA.add(vectorB)
path(Book::price).gt(BigDecimal.valueOf(100))

If so, the above sentence could be rewritten as follows

vectorA + vectorB
path(Book::price) > BigDecimal.valueOf(100)

Unlike QueryDSL, I think this is a sugar syntax that is only possible in Kotlin

If such syntaxes are added, it will be possible to write more intuitive and clearer syntaxes.

Item 1 (condition infix)

Before

After

Item 2 (operation infix)

Before

After

That's all working well.

Item 3 (case when infix)

That doesn't work and might not be a good idea.

Right now it's a dream, but

Why not further develop the domestic K-JDSL and reach 1k?

QueryDSL is a maintenance-only project with virtually no development.

• The sad reality of QueryDSL - 1
• The sad reality of QueryDSL - 2
• The sad reality of QueryDSL - 3

I think Kotlin-JDSL is easier than jOOQ.

I want to let the JVM Kotlin camp know that there is KDSL.

[shouwn]

I've been thinking about the infix and operator overload since I started planning Kotlin JDSL 3.0. But the reason I haven't worked on it until now is that I can't provide a good user interface.

Infix

The infix makes our code look a little more elegant. But does the infix help us when writing code? I think the infix makes writing code more difficult because the compiler doesn't know which operand the infix applies to, which can be seen in the example you gave where you used parentheses.

whereOr(
  ( path(Employee::employeeId) ge 1L ) and ( path(Employee::employeeId) le 2L ),
  ( path(Employee::employeeId) ge 4L ) and ( path(Employee::employeeId) le 5L ),
)

This causes interruptions in development. Because the operators you use later affect the operators before them. You may encounter a compile error in the middle of writing code, and you have to figure out which of the operators you used to add parentheses. Also, the more parentheses you have, the harder it is to understand the code.

To help the infix write code, I think the operand should be defined as Algebraic Data Type (ADT) and the operators should be closed operators. However, operands in the Kotlin JDSL cannot be defined as ADTs. That's why I don't think it's a good idea to support the infix in the Kotlin JDSL.

Operator Overload

The operator overload inherits the problems of the infix, but has another problem which is that parentheses cannot be used as operators.

path(Employee::employeeId) + literalLong(1L) + literalLong(2L) // employee.employeeId + 1 + 2
path(Employee::employeeId) + ( literalLong(1L) + literalLong(2L) ) // employee.employeeId + 1 + 2

Since we can't provide parentheses as an operator, we can't make the parentheses the user used into an actual query. If we could, we would have to add parentheses to the result of each operator. However, as more parentheses are added, the actual query that is generated becomes harder to understand, and we have to generate more and more unnecessary parenthesis objects.

I don't think operator overload is worth the tradeoff.