Implicit sub query styles for kotlin DSL, tell me you choice

[babyfish-ct]

2.

3.

4.

[pot-mot]

4，追求更少的嵌套和更明确的语义。
where += 和原有的 where 一致，且在减少了一层嵌套同时使创建条件这一语义更加明确。
2 中 where {} 在形式上与 where () 没法拉开区别，并且不支持书写多个条件。
3 where (集合属性) {子查询条件} 与 where (条件) 的传统 api 割裂，入参模式不一致，个人认为有些别扭。

[WackyGem]

赞成
选择 4 的原因是 += 有依次追加的语义 ， 如果无可避免拆成多个 where ， += 的表达力更强。
而 3 适合以下这一行的情况
where (table.authors) { firstName eq 'alex' gender eq Gender.MALE }

[ClearPlume]

3，理由如下：

• 语法更直观，明确指明当前针对哪个属性在设置条件
• 更贴近现有设计
• 理解成本低

[ArgonarioD]

3，还算和原本有一些统一的API。

下面是有关其它选项的一些想法：

• 如果 2 可以支持 and 和 or 条件的话，我会选 2，这种高阶函数构造块的方式看起来比较 Kotlin 一些（比如如下面的 html {} 之类的，实现方式可能比如让 eq 这种 function 在执行的时候向构造器添加条件之类的）；

• 4 不能支持一次性添加多个条件的话，看起来可能会多写很多个 where。

上面说的 html {} dsl

html {
    body {
        div {
            a("https://kotlinlang.org") {
                target = ATarget.blank
                +"Main site"
            }
        }
    }
}

相对的 where 的 dsl 可能就？

where {
    table.name ilike "test"
    or {
        and {
            table.publishDate ge (LocalDateTime.now() - 50.hour)
            table.publishDate le (LocalDateTime.now() - 25.hour)
        }
        table.name like "some"
    }
    table.authors {
        firstName eq "Alex"
    }
}
select(table.fetchBy { allScalarFields() })

[pot-mot]

如果讨论不仅仅局限于对隐式子查询的优化的话，我认为这样的 dsl 可以作为未来的发展方向。
符合 kotlin 的美感，也与过去的 API 风格一致。

[babyfish-ct]

相对的 where 的 dsl 可能就？是不可能的，kt lambda最后一句才是返回值

[ArgonarioD]

相对的 where 的 dsl 可能就？是不可能的

这种风格的 dsl 的 where 中的条件语句并不是让 where 方法接收值来添加条件，而是在进行条件中缀函数调用的时候直接向 where 添加条件：

• 直接给查询本身添加
• 或者给 where 的 dsl object 添加，在 where 方法的实现中执行完 block 以后再添加给查询本身

，从而实现在一个 lambda 块中添加多个条件的功能。

kt lambda最后一句才是返回值

是的，所以这个风格相比于目前的实现可能需要一定程度的改动。

[babyfish-ct]

3是不可能的，和TableEx属性打架了

[ClearPlume]

那就4，也挺直观

[draco1023]

现在这种写法是and的情况，想问一下，如果是or又会如何表示

[pot-mot]

or 其实可以看成多个子条件组成的一个复合条件，所以应该继续使用 or (conditions) 这样的写法就可以了。

where += or (
    table.name eq 'a',
    table.name eq 'b'
)

[pot-mot]

同理要表达复合条件时 and () 也就可以避免重复写多个 where 了