/tmp/duangsuse.sock
23 subscribers
303 photos
3 videos
92 files
337 links
从 duangsuse::Echo (@dsuse) 跟进出来的分支,将在作者恢复原帐号访问的时候合并删除。
Download Telegram
Forwarded from Deleted Account
第一种,直白一些
Forwarded from Yuuta 🎀 | clrd enroute
好耶
Forwarded from Deleted Account
a: List<Map<String, JsonValue>>
a: List<User>
a -> b

users.map { it.id to mapOf("admin" to  it.admin) }

b: Map<UserId, UserData>
b -> a

users.map { User(id = it.key, admin = it.value["admin"]) }
Forwarded from Deleted Account
JSON 里数据传输时 array index 是不占用信息熵的
Forwarded from Yuuta 🎀 | clrd enroute
不过在 Query 的时候这个 Index 是多余的
Forwarded from Yuuta 🎀 | clrd enroute
真正有意义的 ID 是 user_id
Forwarded from Deleted Account
你可以中间加一层转化啊。
毕竟这也就是数据表示的区别而已,不应该影响应用本身,很多人不需要那些比较骚的操作也就没做相互转化了,也不是不可以。
Forwarded from Yuuta 🎀 | clrd enroute
怎么转呢?如果我没有 Index 的话
Forwarded from Deleted Account
上面啊,from: Map<UserId, UserData> to List<User>
to: List<User> to Map<UserId, UserData>
Forwarded from Deleted Account
interface Representation<T, T1> {
fun from(source: T): T1
fun to(value: T1): T
}
Forwarded from Deleted Account
就像 1 到 2 再减回来的那个 (+1) (-1)
+1 是 from、-1 是 to。
Forwarded from Deleted Account
对了,唯一性是什么东东。
是不是 Map key 那个唯一性
Forwarded from Yuuta 🎀 | clrd enroute
因为要保证 Array Element 中 user_id 是唯一的
Forwarded from Deleted Account
有道理啊
Forwarded from Yuuta 🎀 | clrd enroute
(想在数据库上直接做,懒得拿服务器实现这个(
Forwarded from Deleted Account
应用,图个开心嘛,平常工作做得就行了。
Forwarded from Deleted Account
都做那么好,用户也看不出来,还浪费 CPU,得不偿失。
Forwarded from Deleted Account
优雅可以弄成模块做,就像 Java 可以选择 assertation 是否 -ea
Forwarded from Deleted Account
不必每次都检查
Forwarded from Deleted Account
其实也没什么的,就是 users.forEach { val name=it.key; val (x,y,z,w) = it.value }……好吧,的确不很好看
Forwarded from Deleted Account
所以我说,数据表示层的东西就放本层解决,不要干扰到其他抽象,那就惨不忍睹了。