Forwarded from dnaugsuz
那你就别改了，要不然你就 refactor 成
估计
getListItemNumberView 的形式估计
MainActivity 里的 View field 真是它自己的，ViewHolder 里的 View，按字面意义上本来就是给别人使用的，自己只是负责持有，所以要 public 给暴露出去（虽然一般我们都会用 getter/setter 而不是裸 field）Forwarded from Rubicon
无标识符默认protected（就是你说的package-private），每个文件只能有一个public class（感觉好像Java是用文件名识别class的），文件名与public class的名称相同，比如example.net.Request 必须在example/net/Request.java
Forwarded from 平行线
字段访问权限无论何时都应该最小化，这是好习惯，就像第一个做的那样
第二个是因为它是作为内部类存在，那个字段要被外部类访问（她只是一个viewHolder），如果作为private外部类在语法上虽然也可以访问，但在编译之后它会生成中间代理get方法来访问private字段，方法调用会消耗性能（另：它作为static class会更好）
第二个是因为它是作为内部类存在，那个字段要被外部类访问（她只是一个viewHolder），如果作为private外部类在语法上虽然也可以访问，但在编译之后它会生成中间代理get方法来访问private字段，方法调用会消耗性能（另：它作为static class会更好）
Forwarded from dnaugsuz
Java 语言的抽象层次比较低，还有 field，Kotlin 里都是自动生成的。
constructor, field, method, inner-class
static field, static method
Kotlin 里一个 class 可以有
constructor, val/var, fun, inner class
而且 Kotlin 里需要在架构器被赋值的量，可以直接写架构器里；并且创建某个 class 的新实例也不需要
private String name;Java 里一个 class 可以有
String getName() { return name; }
void setName(String name) { this.name = name; }
constructor, field, method, inner-class
static field, static method
Kotlin 里一个 class 可以有
constructor, val/var, fun, inner class
而且 Kotlin 里需要在架构器被赋值的量，可以直接写架构器里；并且创建某个 class 的新实例也不需要
new 关键字，所以说 Kotlin 抽象程度更好Forwarded from 平行线
编译之后它将成为 OutterClassName$NumberViewHolder，与外部类关系是同包，外部类在虚拟机层面将无法访问内部类的private字段、方法，Java对于外部类调用内部类的方法、字段的时候会生成包级别（默认）访问权限的Delagate方法来访问
Forwarded from dnaugsuz
没理由为了这种极端情况刻意优化，而且这代价…… 虽然只是 private 到 public，依然不值得
Forwarded from dnaugsuz
显然还有其他代码引用了
ThatViewHolder.listItemView，而那些代码要求 publicForwarded from dnaugsuz
那当然，因为你的 class 里面没引用者，它是 private field，又不是 protected 那
我还以为是就 public/private/protected 它会区分粗体斜体什么的呢……忘记了，有段时间没用 IDEA
class SomeClass extends YourClass 还能访问到我还以为是就 public/private/protected 它会区分粗体斜体什么的呢……忘记了，有段时间没用 IDEA
下去散步的时候想了一下 ParserKt 的 LayoutPattern 处理可选的 layout 的问题，感觉有点复杂
所谓可选的 layout，就是：
ParserKt 里限制非常大，因为是严格的 peek(1)，没法预判
不过对于 if，可以定义这种
LayoutPattern 是基于 item / tail / layout 定义的，有没有 layout 也是取决于 tail 是否解析成功
但由于 ParserKt 全局严重依赖 Type nullability （也就是 Optional<T>）所以不可能在 tail 里做到区分 layout/非layout 的语法
我想到了一个方法，就是把
+ 如果结果是
+ 如果结果是
所谓可选的 layout，就是：
if p: op() #无和带不带花括号的区分方式处理上差别不太大，都是判 1 字符。
if p: #有
op1()
op2()
ParserKt 里限制非常大，因为是严格的 peek(1)，没法预判
不过对于 if，可以定义这种
Pattern<Char, AST> 。LayoutPattern 是基于 item / tail / layout 定义的，有没有 layout 也是取决于 tail 是否解析成功
但由于 ParserKt 全局严重依赖 Type nullability （也就是 Optional<T>）所以不可能在 tail 里做到区分 layout/非layout 的语法
我想到了一个方法，就是把
\n 字符从 layout 的 prefix item('\n') 里拉回 tail 里，跳过 whitespace 和 ':' 后看是否换行，然后再基于整个 LayoutPattern 的结果，Piped + 如果结果是
Expr，则代表非 layout 语法，继续 read 一个 expression 并且组织 IfExpr+ 如果结果是
IfBlock，则代表 layout 语法，直接返回结果Forwarded from dnaugsuz
Arrow 实在是太可怜了，开始我看几个 parser combinator 库依赖它，还以为它是个 big guy 呢 🤪