update data class doc to use extension properties

Author: vincentlauvlwj

docs/source/en/define-entities-as-any-kind-of-classes.md

@@ -54,6 +54,8 @@ object Staffs : BaseTable<Staff>("t_employee") {
         sectionId = row[sectionId] ?: 0
     )
 }
+
+val Database.staffs get() = this.sequenceOf(Staffs)
 ```
 
 As you can see, the `Staff` here is just a simple data class. Ktorm doesn't have any special requirements for this class. It is no longer necessary to define it as an interface, which minimizes the intrusion of the framework to user code. The table object `Staffs` is also defined as a subclass of `BaseTable` and implements the `doCreateEntity` function, in which we get columns' values via square brackets `[]` and fill them into the data object. 
@@ -73,8 +75,7 @@ val staffs = database
 Obtain entity objects via sequence APIs, and sorting them by the specific column: 
 
 ```kotlin
-val staffs = database
-    .sequenceOf(Staffs)
+val staffs = database.staffs
     .filter { it.sectionId eq 1 }
     .sortedBy { it.id }
     .toList()
@@ -83,8 +84,7 @@ val staffs = database
 Get the number of staffs with a salary of less than 100 thousand in each department: 
 
 ```kotlin
-val counts = database
-    .sequenceOf(Staffs)
+val counts = database.staffs
     .filter { it.salary less 100000L }
     .groupingBy { it.sectionId }
     .eachCount()
@@ -97,6 +97,6 @@ For more usages, see the documentation of [SQL DSL](./query.html) and [Entity Se
 However, data classes are not perfect, and that's why Ktorm decided to use `Entity` interfaces when it was originally designed. In fact, even after Ktorm 2.5 released, defining entities as interfaces is still our first choice because there are currently two limitations to using data classes: 
 
 - **Column bindings are not available:** Since `BaseTable` is directly used as the parent class, we cannot configure the bindings between database columns and entity properties via `bindTo` and `references` while defining our table objects. Therefore, each table object must implement the `doCreateEntity` function, in which we should create our entity objects manually. 
-- **Entity manipulation APIs are not available:** Since we define entities as data classes, Ktorm cannot proxy them and cannot detect the status changes of entity objects, which makes it impossible for us to use entity manipulation APIs such as `database.sequenceOf(..).add(..)`, `entity.flushChanges()`, etc. But SQL DSL is not affected. We can still use DSL function such as `database.insert(..) {..}` and `database.update(..) {..}` to perform our data modifications. 
+- **Entity manipulation APIs are not available:** Since we define entities as data classes, Ktorm cannot proxy them and cannot detect the status changes of entity objects, which makes it impossible for us to use entity manipulation APIs such as `sequence.add(..)`, `entity.flushChanges()`, etc. But SQL DSL is not affected. We can still use DSL function such as `database.insert(..) {..}` and `database.update(..) {..}` to perform our data modifications. 
 
 Because of these limitations, you should think carefully before you decide to define your entities as data classes. You might be benefited from using data classes and you would lose other things at the same time. Remember: **Defining entities as interfaces is still our first choice.** 

docs/source/zh-cn/define-entities-as-any-kind-of-classes.md

@@ -54,6 +54,8 @@ object Staffs : BaseTable<Staff>("t_employee") {
         sectionId = row[sectionId] ?: 0
     )
 }
+
+val Database.staffs get() = this.sequenceOf(Staffs)
 ```
 
 可以看到，这里的 `Staff` 只是一个单纯的 data class，Ktorm 对这个类没有任何特殊的要求，不再需要把它定义为 interface，把框架对用户代码的侵入性做到了最低。`Staffs` 表对象在定义的时候也改为继承 `BaseTable` 类，并且实现了 `doCreateEntity` 函数，在里面使用方括号语法 `[]` 获取每个列的值填充到数据对象中。
@@ -73,8 +75,7 @@ val staffs = database
 使用序列 API 获取实体对象，并按指定字段排序：
 
 ```kotlin
-val staffs = database
-    .sequenceOf(Staffs)
+val staffs = database.staffs
     .filter { it.sectionId eq 1 }
     .sortedBy { it.id }
     .toList()
@@ -83,8 +84,7 @@ val staffs = database
 获取每个部门中薪资小于十万的员工的数量：
 
 ```kotlin
-val counts = database
-    .sequenceOf(Staffs)
+val counts = database.staffs
     .filter { it.salary less 100000L }
     .groupingBy { it.sectionId }
     .eachCount()
@@ -97,7 +97,7 @@ val counts = database
 如果 data class 真的那么完美的话，Ktorm 在最初设计的时候就不会决定使用 `Entity` interface 了。事实上，即使在 2.5 版本发布以后，使用 interface 定义实体类仍然是我们的第一选择。与使用 interface 定义实体类相比，使用 data class 目前还存在如下两个限制：
 
 - **无法使用列绑定功能：**由于直接以 `BaseTable` 作为父类，我们无法在定义表对象时使用 `bindTo`、`references` 等函数指定数据库列与实体类属性的绑定关系，因此每个表对象都必须实现 `doCreateEntity` 函数，在此函数中手动创建实体对象，并一一对各个属性赋值。
-- **无法使用实体对象的增删改 API：**由于使用 data class 作为实体类，Ktorm 无法对其进行代理，因此无法检测到实体对象的状态变化，这导致 `database.sequenceOf(..).add(..)`、`entity.flushChanges()` 等针对实体对象的增删改 API 将无法使用。但是 SQL DSL 并没有影响，我们仍然可以使用 `database.insert(..) {..}`、`database.update(..) {..}` 等 DSL 函数进行增删改操作。
+- **无法使用实体对象的增删改 API：**由于使用 data class 作为实体类，Ktorm 无法对其进行代理，因此无法检测到实体对象的状态变化，这导致 `sequence.add(..)`、`entity.flushChanges()` 等针对实体对象的增删改 API 将无法使用。但是 SQL DSL 并没有影响，我们仍然可以使用 `database.insert(..) {..}`、`database.update(..) {..}` 等 DSL 函数进行增删改操作。
 
 由于以上限制的存在，在你决定使用 data class 作为实体类之前，应该慎重考虑，你获得了使用 data class 的好处，同时也会失去其他的东西。请记住这句话：**使用 interface 定义实体类仍然是我们的第一选择。**