#PLT 绝句 最近的变更：
决定移除『扩物』，从此简记法是「储例况标内抽象」
原因有二：
从编程惯用来看，会连续创建多个 receiver 类型不同的 ext fun/val ，扩物的写法有悖常理
从语言一致性来看， Kotlin 的 receiver/param1 互化带来的 fun(type) with receiver 与「扩物」不对仗（关于知识网的联系就换成所有 fun/val 都隐式于『我类型』好了）
而且即便标物和抽象物也都是『物』，可扩物实际上只是种蹩脚的编译元数据定义
决定将 抽象/开放/终定 变为 待定/再定/终定 ，『抽象性/覆写性』为『确定性』
对应 abstract/open/final
TODO() 则是 待写()
从兼容性上， open 也可视为可见性修饰符，语义匮乏，没必要移植到中文
现在，只有 储例况标内
expect/actual 仍 待例/实际
可见性： 公开 族内 私下 内部
覆写性： 开放 终定 抽象 实现
特殊：隐式 记法
内联 不联
待例 实际
晚成 尾递归 断续
决定移除『扩物』，从此简记法是「储例况标内抽象」
原因有二：
从编程惯用来看，会连续创建多个 receiver 类型不同的 ext fun/val ，扩物的写法有悖常理
从语言一致性来看， Kotlin 的 receiver/param1 互化带来的 fun(type) with receiver 与「扩物」不对仗（关于知识网的联系就换成所有 fun/val 都隐式于『我类型』好了）
而且即便标物和抽象物也都是『物』，可扩物实际上只是种蹩脚的编译元数据定义
决定将 抽象/开放/终定 变为 待定/再定/终定 ，『抽象性/覆写性』为『确定性』
对应 abstract/open/final
TODO() 则是 待写()
从兼容性上， open 也可视为可见性修饰符，语义匮乏，没必要移植到中文
现在，只有 储例况标内
expect/actual 仍 待例/实际
可见性： 公开 族内 私下 内部
覆写性： 开放 终定 抽象 实现
特殊：隐式 记法
内联 不联
待例 实际
晚成 尾递归 断续
duangsuse::Echo
#PLT 绝句 最近的变更： 决定移除『扩物』，从此简记法是「储例况标内抽象」 原因有二： 从编程惯用来看，会连续创建多个 receiver 类型不同的 ext fun/val ，扩物的写法有悖常理 从语言一致性来看， Kotlin 的 receiver/param1 互化带来的 fun(type) with receiver 与「扩物」不对仗（关于知识网的联系就换成所有 fun/val 都隐式于『我类型』好了） 而且即便标物和抽象物也都是『物』，可扩物实际上只是种蹩脚的编译元数据定义 决定将 抽象/开放/终定…
绝句的面向对象架构现在已经和 Java 面向对象，乃至 Kotlin 的正统 OOP 都有点差异了
visibility/可见性:
公开 族内 私下 内部
public protected private internal
rewritability/确定性:
待定 再定 终定 实现
abstract open final override
construct/构件:
包 类型别名 常量 类 物 例 造于 事 量/变
package typealias const-val interface class object constructor fun val/var
package typealias const class thing insta constructor fun val/var
affairs/杂件:
取者 置者 代者 恒事 性质推导
get set by
class kinds/类定义的种类:
储 例 况 标 内 待定
data enum sealed annotation inner abstract
multitarget/多平台:
待例 实际
expect actual
others/其它:
晚成 尾递归 断续 隐式 记法
lateinit tailrec suspend implicit notation
内联 不联
inline noinline
access/访问:
(o的n) (o去v) (o[k]) (k存于o)
(o.n) o.v() o[k] (k in o)
type RHS/类型:
属于 作成 试作
is as as?
visibility/可见性:
公开 族内 私下 内部
public protected private internal
rewritability/确定性:
待定 再定 终定 实现
abstract open final override
construct/构件:
包 类型别名 常量 类 物 例 造于 事 量/变
package typealias const-val interface class object constructor fun val/var
package typealias const class thing insta constructor fun val/var
affairs/杂件:
取者 置者 代者 恒事 性质推导
get set by
class kinds/类定义的种类:
储 例 况 标 内 待定
data enum sealed annotation inner abstract
multitarget/多平台:
待例 实际
expect actual
others/其它:
晚成 尾递归 断续 隐式 记法
lateinit tailrec suspend implicit notation
内联 不联
inline noinline
access/访问:
(o的n) (o去v) (o[k]) (k存于o)
(o.n) o.v() o[k] (k in o)
type RHS/类型:
属于 作成 试作
is as as?
duangsuse::Echo
绝句的面向对象架构现在已经和 Java 面向对象，乃至 Kotlin 的正统 OOP 都有点差异了 visibility/可见性: 公开 族内 私下 内部 public protected private internal rewritability/确定性: 待定 再定 终定 实现 abstract open final override construct/构件: 包 类型别名 常量 类 物 例 造于 事 量/变 package typealias const-val interface class…
所以大家可以看到，表达用的语言，对编程语言的模样是有影响的。 试问按英文设计能弄出 待定/再定/终定 的区别吗？恐怕很鸡肋，甚至不如 abstract/open/final
顺便，命名风格和参数顺序对结果可读性也会有影响，它们也会间接影响到 API 的设计。
顺便，命名风格和参数顺序对结果可读性也会有影响，它们也会间接影响到 API 的设计。
duangsuse::Echo
绝句的面向对象架构现在已经和 Java 面向对象，乃至 Kotlin 的正统 OOP 都有点差异了 visibility/可见性: 公开 族内 私下 内部 public protected private internal rewritability/确定性: 待定 再定 终定 实现 abstract open final override construct/构件: 包 类型别名 常量 类 物 例 造于 事 量/变 package typealias const-val interface class…
#dev #design 在这里谈下自己对 「待定/再定/终定」 新写法的看法吧。
加了这个以后我一直觉得很难受（一部分也是我在考虑无GC的『存储』子类如何实现），因为某种意义上这是在否定过去的设计“特性”——绝句在这方面之前和 Kotlin 不一样，我试着把『抽象性』隔离了出来（作为 抽象物 这个关键字），然后 open 和 final 保持不变（因为 abstract class 几乎是一个惯例，有理由为其分配关键字）
从用法上看， final 只在指定 open class 里不可再定的成员时才使用，频率最少；open 的频率在其次，另外如果要减轻
新名称也是符合绝句设计惯例的——待定/再定/终定 对毫无编程经验的人也容易理解（日常用语），并且一定程度隐含了底层方法解析确定性的语义。
可是现在又改回来了——
抽象物『标物处理器』为
待定的物『标物处理器』为
再定的物『活动』为
为了这三个“X定”的一致性，是不可能再弄『待定物』这样的关键字的，而目前就打回原形、和 Kotlin 一样，真的很不爽啊（最讨厌设计得和别人一样了，但我不得不承认这是最好的做法）。
加了这个以后我一直觉得很难受（一部分也是我在考虑无GC的『存储』子类如何实现），因为某种意义上这是在否定过去的设计“特性”——绝句在这方面之前和 Kotlin 不一样，我试着把『抽象性』隔离了出来（作为 抽象物 这个关键字），然后 open 和 final 保持不变（因为 abstract class 几乎是一个惯例，有理由为其分配关键字）
从用法上看， final 只在指定 open class 里不可再定的成员时才使用，频率最少；open 的频率在其次，另外如果要减轻
interface X { abstract val a:Int } 这种不优雅的有效语法对程序明确性的影响，我觉得不应该沿用老名称。新名称也是符合绝句设计惯例的——待定/再定/终定 对毫无编程经验的人也容易理解（日常用语），并且一定程度隐含了底层方法解析确定性的语义。
可是现在又改回来了——
抽象物『标物处理器』为
待定的物『标物处理器』为
再定的物『活动』为
为了这三个“X定”的一致性，是不可能再弄『待定物』这样的关键字的，而目前就打回原形、和 Kotlin 一样，真的很不爽啊（最讨厌设计得和别人一样了，但我不得不承认这是最好的做法）。
说白了我就是不想否定之前设计的有效性……（当然它也带来了 抽象/实现(override) 的这个配对）
关于面向对象 继承、抽象、多态 三特性绝句到底什么该抄，什么该再定，以前也是真的没好好想过（单纯觉得怎么方便怎么弄了），一直在探索而已。 😓
关于面向对象 继承、抽象、多态 三特性绝句到底什么该抄，什么该再定，以前也是真的没好好想过（单纯觉得怎么方便怎么弄了），一直在探索而已。 😓
Forwarded from moke 的 日常分享、吐槽和动态
《免代理爬取并下载 Pixiv 图片》
https://www.v2ex.com/t/715042
这东西都好意思卖钱我是没想到的
虽说买卖自由吧，但你这收费app居然用的还是别人爬好的链接，等于偷别人的东西包装了一下就来卖了
https://www.v2ex.com/t/715042
这东西都好意思卖钱我是没想到的
虽说买卖自由吧，但你这收费app居然用的还是别人爬好的链接，等于偷别人的东西包装了一下就来卖了
Forwarded from Rachel 碎碎念 (IFTTT)
pic.twitter.com/qRewgWmdNw
— A meme page to check every time MatLab crashes (@memecrashes) October 15, 2020
— A meme page to check every time MatLab crashes (@memecrashes) October 15, 2020
Twitter
A meme page to check every time MatLab crashes
https://t.co/qRewgWmdNw
Forwarded from Rong布星球 🧶 (Rongrong🍨 | 高萌酸钾)
#人间迷惑行为
https://github.com/DIYgod/RSSHub/pull/5886
我自己清楚自己订阅的是谁的微博，阅读器也会显示头像和名字，还用你把博主名字和头像写在正文里?
让 RSS 时间线化，舍本逐末。
https://github.com/DIYgod/RSSHub/pull/5886
我自己清楚自己订阅的是谁的微博，阅读器也会显示头像和名字，还用你把博主名字和头像写在正文里?
让 RSS 时间线化，舍本逐末。
GitHub
feat: more readable 微博个人时间线, Twitter 用户时间线, 豆瓣用户广播 by shunf4 · Pull Request #5886 · DIYgod/RSSHub
目的 / What this PR does
更可读的微博个人时间线、Twitter 用户时间线、豆瓣用户广播
可能修复了 bug
潜在地引入了新的 bug
该 PR 相关 Issue / Involved issue
无
完整路由地址 / Example for the proposed route(s)
https://rsshub.app/douban/people/1138...
更可读的微博个人时间线、Twitter 用户时间线、豆瓣用户广播
可能修复了 bug
潜在地引入了新的 bug
该 PR 相关 Issue / Involved issue
无
完整路由地址 / Example for the proposed route(s)
https://rsshub.app/douban/people/1138...