#Kotlin #OOP #Question

可是我不擅长设计模式啊... Adapter 给人的感觉就是接受数据，然后提供对应操作的。比如 NumericAdapter 可能接受 LongNumber 和 StringNumber 状态实例，提供 plus / minus 等操作...

至于这个 Polymorphism，中文名即为多态。含义就只是『不同的东西用一个名字』而已，比如面向对象的方法重载(overloading)就属于特殊多态(ad-hoc polymorphism) 的一种

面向对象的多态有子类型多态、类型转换多态、函数重载、参数化类型等等（虽然我不知道那些是什么，2333)

大家在使用 JavaEE 的 Beans 特性的时候应该可以注意到 BeanManager 要拿一个 Bean 组件的实例（getBeans&resolve），得提供它的参数化类型（getRawType、getActualTypeParameters），可能 kotlinx.serialization 的那个也是一个用。

所以这个 ktx 的多态支持是什么呢...

等等，我看下....

我也是... 完全没有注意到它要干什么，可能的确是要运行时生成子类实现吧？

既然出现了 Animation ，一般认为都是关于前端的事情吧，可是这明明是序列化，对数据表示方式的变换（所以它只是一个用例啊...）。

我只知道，如果开发者写一个 class UserPhotoInptMedia(): InputMedia() 就可以直接在代码里访问到 companion object 里的 module 了，或许是这么用：

val buffer = InputMedia.module.serialize(mike.getAvatar() as UserPhotoInputMedia)

SerializersModule 可能是一个类的构造器，接受一个 SerializersModule.() -> Unit 吧... 这是 Kotlin DSL 的经典『初始化器』模式，和 Groovy 那个一个暖样。

关键在于 polymorphic 方法，它可能要反射这个 KClass<InputMedia>... 然后为下面初始化 Block 里的语句做 self 的依赖数据。

InputMediaAnimation::class with InputMediaAnimation.serializer() （ with 是 Kotlin 的 infix 方法 ）这明显是反映了一个 Mapping 的数据结构，利用副作用把每个子类型多态子类映射到它的 Serializer<in T>, 这么一看就联系起来了，整个 serializer 架构的 context 就是某个作用域的 Map<KClass<*>, Map<KClass<*>, Serializer<*>> 大概（没法类型安全，所以只能使用 * ）

然后目标是把 Person 的许多子类比如 Teacher / Boss / Developer / Police 给指定不同的 Serializer<T> 实例，进行序列化的多态。本来就不应该乱用设计模式的... 原来的方法可能要你专门去提供一个 Type 来拿 Serializer<T> 比如

InputMedia.module.serializeToStandareOut(mike.photos.getFirst(), PolymorphismTypeAdapter(PhotoMedia::class)) 这种，Runtime 的那个用 Java 的反射元编程依赖输入对象自动创造 TypeAdapter 的就太魔法了。开始手动去指定子类型的 serializer 实例也好，但是不如这么做明确...

不过也有会这么干的：

interface DecidableSerizer<T> { fun getSerializer(): Serializer<T> }

然后每个接口实现都可以 `override fun getSerializer() = my_serializer`，不过这样就不 DSL 了。
（刚才 Doge 酱的 MTProto 不稳定，所以没发出来）

总是觉得 StateMachine 模型会好很多，状态机好魔法啊，状态、状态转换图、切换状态、状态变迁、同步信号、异步信号...

看看这个 class JSFormat https://github.com/aiastia/testssr/blob/dev/shadowsocks/shell.py#L436 好高端的样子，文本处理就应该用状态 🐔

状态机的确是一个很通用的模型（程序计数器也可以理解为基于 counter 的特殊状态机），而且非常有用，尤其是针对 GUI 程序的设计（比如某种状态下，接受到某个信号应该做什么、再切换到什么状态），推荐了解一下。

...其实不管怎么样，从仅仅是不强调思路清晰而已到复制粘贴代码是一件很可怕的事情，D(o not)R(epeat)Y(ourself) 原则啊，机器人才复制呢。推荐你写一个 Gradle task 从某种 input file 生成代码填进到 outputs.file 里... 之前大佬应该也听说过苏上个暑假写 GeekApk （虽然最后没有完成...）的时候，一大堆接口 mapping 都不是靠复制粘贴得来的... Kotlin 代码生成程序还算是简单的，我根本不会写 LLVM 编译器

我在写这个，目前已经完成了

写的时候很是感叹空纸上谈兵和实践果然还是不一样啊 #Lua #dev

我之前在学校里看了《Lua 设计与实现》里类似这些的代码，自以为很了解并且能写出更好看的代码，
可还没有两秒钟就被自己的愚蠢打脸了... 我有一个优化没看见

其实这些数据依赖、数据操作的模拟分析和回溯，又有多么简单呢。它们的复杂性需要大量的实践经验去填补。

想到要写只是一会的事情，刚准备写的时候冷汗直冒... 原来我其实一直都没有彻底理解 而已
我靠的大部分是记忆，不是抽丝剥茧。

不过还好，我还是最终通过自己勉强有一点的直觉想到了该怎么写... 并且在三十分钟内完成了总体的程序，之后一直在调试。

第一次我把 {__newindex=mkmember } 写错为 {__newindex, mkmember} 导致莫名其妙 bug 的出现，花了我好长时间...
第二次我不知道 __newindex 对应的 rawset, 上网查了第一次
第三次我写 local helper=function()... 但不知为何错误，改成了 local function helper()...
我也修改了不少次递归查找的函数。

最后我还是证明了开始写的程序，总体逻辑是正确的。
代码一共 80 多行，不多，但是我已经开始从理论走向编程。

我准备将它整理，添加一个非 Prototype 的方式（call super 链）
并且附上 LinkIterable, InvocationChain 的实现，
顺便加一个 Lua C 函数编写的简易示范发上 essay.

想要试用的同学：

require 'oop'
animal = inherit.class()
animal.ctor = function(o, id) o.name= id end
function animal:describe() print("我叫" .. self.name) end
cat = inherit.class(animal)
cat.ctor = function(o, id) o.name= "猫" .. id end
meo = cat.new('喵喵')
meo:describe()

说起来，因为有这个小号的原因
我知道 drakeet 曾经研究的反破解也的确是取得了一些进步，至少他都知道我能找到『黑箱』里的符号了
当然，作为 C 开发者我也是知道怎么办的，CC -fvisibility=hidden, __attribute__((visibility("hidden"))), static, LD --exclude-symbols, strip -K Java_io_Main_digest 都可以

可惜 drakeet 虽然的确是从我曾经的逆向工程经验里学到了很多应对经验了... 我觉得这很不错
这和『无懈可击』还是蛮不一样的。

我在编译原理上也有进步，实际上，他改进之后的『反破解』，也未必是真的无懈可击... 他依然是并没有给出破解动态调试的方法，进步了，在添加无用代码混淆视听了，但是这对基于关键方法断点的动态调试手段没有本质上的改善。用『空白字符』『不可打印的字符』也是没有用处的，他们都不是本质。本质仅仅是引用，写过 Haskell、LLVM IR 用过惰性求值你就知道。

弄了半天我才知道之前 -assumenosideeffects kotlin.Intrinsics 的原因居然是为了反破解（可惜现在大部分猴子好像还没有自动代码重构的能力...）
不过有一件事情不一定知道：side effect 死代码消除是 ProGuard 优化代码的手段（之前是不是只把这个玩意当成混淆器呢？），你以为它是说删除 Intrinsics 调用，可实际上它是说删除『返回值没有被使用的』Intrinsics 调用，结果正常只是因为 Intrinsics 对象的方法只是使用副作用(side effects) 而已，这也是我琢磨一会后猜的。

这是(猴子/老鼠)和猫不一样的地方。
猴子总比你知道多一点、深一层，猴子编程的同时训练自己的记忆不靠 StackOverflow。
因为猴子不怕失败，不会浅尝辄止，猴子向往的是背后的东西，只把使用层面当配菜慢慢品尝。

猴子还是老鼠... 可是如果站到了更高的层次，如果已经是程序设计者，还是不一样的吧。

简而言之，我看了一部分后觉得他维护的果然还是变勤快了。
而且内容质量看起来也是高了不少，虽然还算是意料之中，分享的大部分还是停留在使用层面...

两个看到了想说什么的：

1. native 中不依赖 PackageManager 和 signature API 进行签名验证的方法
猜测：
a. 手动算 file 再算 dex hash 和长度什么的，总之就是利用文件系统
b. 找几个应用类算代码 hash 校验，不过实际上这也不叫签名验证
c. JNI 是否 Android 有提供验证的方法
d. 检查重新打包时一切可能发生改变的东西，比如安装包大小？APK 的路径完全可以用 native 的系统 API 得到，不依赖 Java API。

drakeet 早就说过他可以，不过具体怎么办恕我无才，我就猜不出了，而且我不打算再去当甚么猴子，当成迷吧。
但是，如果还有下一次，恐怕我会当成迷的东西真的会少很多。

2. Kotlin 里使用 Number.dp 扩展属性而不是 Number.dp()

开始我套了一下：JavaScript 里 String.prototype.bold 是不是也得变成『accessor』呢
后来自认为是 DSL 方便点而已。 10.dp 不是比 10.dp() 好看么，虽然在符合直觉上有争论（显然第二个语义上有 10.makeAs(dp) 的意思，第一个则从表述上取胜）。

至于 Android 和 Java 开发/日常部分我不熟悉也就不看了，关于逆向和代码保护的标题我看了，也就是防猴不防人。

没做 OCR 的原因是机器太卡了...

... 我打算浅尝辄止了，因为事情的确比较多... 我不想在 #Lua 和 #OOP 上花太多精力
简单讲一下，LinkIterable 和 InvocationChain 也非常简单，LinkIterable
take 一个 object、一个 chainf、一个 hasnextf，具体怎么做就是通过 hasnextf 确认是否有下一项、 chainf 箭头完成状态切换。
InvocationChain 就是 ListIterator 控制，使用完全相同参数调用的函数 chain 而已，利用副作用在受管函数间传递，实现了 OOP 的 call-super chain 模式（不过不能做到在没有 call 的时候自动调用，需要额外添加处理余项的逻辑）

Lua 的 C 用户接口使用 lua_ 开头，Lua 支持 C Closure。
非 prototype 的意思就是：

Prototype 使用 prototype 创建（初始化）对象
prototype 也可能有自己的 prototype，prototype 创建先 call 自己的 prototype 初始化目标对象，再 call 自己的 initializer(constructor)

非 prototype 就是类似 Java 的实现方法，自动生成 call-super 调用，保证初始化都做过了。

class Animal(id: Int, name: String, friendly: Boolean = true)
class Cat(nick: String, fur_color: Cat.Property.FurColor): Animal(0, "cat", true)
class MagicAnimal constructor(id: Int, name: String, friendly: Boolean): Animal(id,name,friendly)

Kotlin 里这种行为比 Java 8 里明显（MagicAnimal 明明没有专门定义子类型的架构器，可还是用了 Animal()）。

class MagicAnimal extends Animal {}

Lua OOP 的这个事情不发就可以了。（逃跑

对 Lua OO 的理解不够深入，vtable 的 meta 方法向上查找没有注意到。

本来应该是实例 __index 到本 class 的 vtable 找，每一 class 的 vtable 找不到就到上层找，我的是实例级别包办一切。
而且我不知道可以给 __index 指定一个 table 作为代理...

Telegram 连接总是不太平... 唉，doge 酱的 Telegram Web 勉强可以用

待会我打算先写篇文章（因为 npm install -g web-ext 垃圾成功不了，NPM 是基于 GIt VCS 的包管理... 某 maintainer 手贱写错部署配置了）

标题是《状态机模型、分词器、解析器、解释器》
画点 dia...

#hw http://esp8266.net/ 突然又在 @YuutaW 的分享里看到了奇怪的东西... 这不是电子嵌入式和无线系的么

我修改了一下，平复了思路上的区别... 的确是我辣鸡不少，本来递归查找就应该是虚表级别的事情，我却让实例级别来做。

顺便 #fix 一下：
之前消息 https://t.me/dsuse_tmp/11 里的『某个作用域』应为『某个生存周期(lifetime)』