标签：app init 生成 dom 对象 nbsp 组织 而不是 实例
https://mp.weixin.qq.com/s/z2gUYuYQAHQCa_5HZcBszw
介绍各个配置项的组织方式。
参考链接：
1. Parameters的chain方法
chain方法用于实现find方法，即查找逻辑：
?
?
其使用链式查找的方法，逐个查找各个配置，直到查到所查的key。
chain方法所属对象（this）、三个参数，标识着配置链表的不同位置、要查找的key：
a. pname：要查找的Key;
b. site: 整个配置链表；
c. this：当前正在查找的配置项；
d. tail: 配置链表中this配置项之后的配置项；
2. PartialParameters的chain方法
PartialParameters中chain方法的实现如下：
?
?
其函数成员f使用的参数，就是当前的查找上下文。如下：
a. site: 整个配置链表；
b. this：当前正在查找的配置项；
c. tail: 配置链表中this配置项之后的配置项；
3. Config的第二个构造方法
?
?
第二个构造方法（secondary constructor），根据传入的参数f，生成一个PartialParameters，然后作为参数调用第一个构造方法（primary constructor）。
4. 实例
?
?
BaseSubsystemConfig继承自Config类，实例化时调用Config的第二个构造方法。
这里的(site, here, up)是形式参数，实际调用时的参数在PartialParameters类中传入，为(site, this, tail)。意义如下：
a. site/site: 整个配置链表；
b. this/here：当前正在查找的配置项；
c. tail/up: 配置链表中this配置项之后的配置项；
5. 配置项之间的依赖关系
某一个配置项可能依赖于其他配置项的值，如BaseSubsystemConfig中的PgLevels依赖于XLen：
?
?
获取所依赖配置值的方式就是通过site进行查找，也就是在整个配置链表中进行查找。
6. 配置项之间的覆盖关系
1) 因为查找是链式的，所以如果两个配置项含有同一个key，那么排在前面的key的值就会被使用。
如DefaultRV32Config：
?
?
WithRV32中也定义了XLen这个配置项，他排在BaseSubsystemConfig中的XLen之前。所以针对DefaultRV32Config的实例使用site(XLen)时，获取到的是32，而不是64。
?
?
2) 排在前面的配置项也可以使用排在后面的配置项的值，并对其进行更改。
同样如DefaultRV32Config。
?
?
WithRV32中的配置项RocketTilesKey，使用up(RocketTilesKey, site)查找配置链表中后续配置项中的RocketTilesKey，并对其进行修改。
这里是可以查找到的，因为DefaultConfig中也定义了RocketTilesKey这个配置项。
7. Config的子类们
如下链接整理并列出了所有Config的子类：
?
? Rocket - config - Configs
标签：app init 生成 dom 对象 nbsp 组织 而不是 实例
原文地址：https://www.cnblogs.com/wjcdx/p/10354813.html
