leobert
leobert
当生成对象时，利用 `org.litepal.crud.DataHandler#findBestSuitConstructor` 找到了一个最合适的构造器， 如果这个构造器是一个有参构造器，且有空指针风险时，例如： ``` public class Bar extends LitePalSupport { public int i; public String s; public Bar(BarArg arg) { i = arg.i; s = arg.s; } public Bar(@NonNull...
之前一些朋友提过疑问：为什么readerComponent已经标明isRegisterCompoAuto = false但是被集成到宿主中时，其APPLike还是被初始化了。 当时这些朋友被我误导了。原有设计中，isRegisterCompoAuto代表的是，以该Module作为宿主编译时，寄生的Module是否被自动集成（注意，是全部） long long ago的时候在群里面讨论过这个设计，我是期望设计成寄生Module被集成时是否被自动集成（没记错当时是插件1.1.0版本）所以一直有这样一个映像在脑海中。 进过一些思考，这两种设计都有利弊，所以我在原有的设计上进行了一定的增强： * isRegisterCompoAuto 依旧代表寄生的Module是否采取自动集成 *添加一个注解标识某些Module规避自动集成。 原来的issue并没有找到，新提一个。
In the service provider interface: `io.sweers.inspector.compiler.plugins.spi.InspectorExtension`, the default implement for `Set applicableAnnotations()` return a empty set, as effect, nothing will be generated for a simple pojo class with `GenerateValidator` notation....
是的，目前的设计看起来很别扭。 从核心设计看，用了解释器模式。诚然，我尝试定义了一种新的表达式语法，并且存在大量的非终结符，然而，终结符却没有给出”显而易见“的代码定义。 以一个简单的例子对比下： 解释（_计算_）”1+2“， 使用解释器模式时，”+“ 将作为非终结符表现，其含义在内部封装，解释时产生实质作用。 1、2是终结符，笼统的讲，终结符表达的是实际的内容或上下文中内容的代号。 在Davinci中，终结符可以是：尺寸、颜色等。 而别扭的地方正在于此。Android中的尺寸和颜色等也有大量的定义方式，尺寸还有各种单位，它不像”1、2“这种数值一样纯粹；并且**很难** 且 **不适合** 直接加载到解释器上下文中。早期版本的设计中并没有理会这一点！
在Compose中使用Glide？我写了一堆Bug！
1. 分析Glide中对于缓存模块的设计以及编解码的设计 2. 抽象问题为模型，寻找类似的问题 3. 讨论这些设计是否可以用于其他问题的解决 4. 对于这些问题的普遍做法是否存在明显缺陷