一文读懂 Magnolia深度解析类型类自动派生的实现原理【免费下载链接】magnoliaEasy, fast, transparent generic derivation of typeclass instances项目地址: https://gitcode.com/gh_mirrors/ma/magnolia接手一个已有三年历史的 Scala 项目时你可能遇到过这样的场景为了让三个嵌套的case class和一个密封特质支持比较与输出你在两个文件里手写了几百行Eq、Show样板代码。而 Magnolia 正是为消灭这种重复劳动而生的——它通过join与split两个核心方法在编译期为任意产品类型与和类型自动生成类型类实例让你从复制粘贴中彻底解放出来。一句话概括 Magnolia它把类型的形状信息有几个字段、有哪些子类和类型类的组合策略彻底分离。形状信息由编译器提供组合策略由你只写一次剩下的递归与分发全部自动完成。下面这张图先帮你建立全局印象本文的每一节都会回到它从一个让人抓狂的场景说起假设你要为下面的模型写一个相等比较器case class Address(city: String, street: String, zip: Int) case class Person(name: String, age: Int, address: Address) sealed trait Event case class Login(p: Person, at: Long) extends Event case class Logout(at: Long) extends Event手写Eq[Person]时你得取出name、age、address三个字段分别比较而比较address又要重复一遍它的三个字段更麻烦的是Event这种密封特质比较前还得先判断两个值到底是不是同一个子类。字段一多、层级一深代码量呈几何级数膨胀。Magnolia 的思路非常直白这类推导是有固定配方的。case class 的实例等于所有字段实例的组合密封特质的实例等于按实际子类选择一个实例。只要把这两个配方写一次剩下的交给编译器自动套用。这正是join与split名字的由来。为什么非要有元数据这层设计先抛个问题为什么不直接用宏生成全部代码非要先造出CaseClass、SealedTrait这些运行时对象答案是关注点分离。纯宏方案里取字段、判断子类这些底层操作和如何组合类型类的高层策略纠缠在一起每写一个新类型类都要重新和宏 API 搏斗。Magnolia 选择在中间插入一层形状元数据编译期用 Scala 3 内置的Mirror拿到类型的形状字段列表、子类型列表、类型参数运行期把这套形状封装成CaseClass/SealedTrait对象字段的取值deref、构造construct、子类判断cast都通过它们完成你写的join/split只负责如何利用这套形状完全不关心形状是怎么来的。这层设计带来三个实际好处一是类型类作者只需要理解几个直观的 API二是元数据惰性求值性能可控三是注解、默认值、重复参数这些旁路信息可以统一塞进元数据join/split拿起来就能用。核心机制一join——把零件拼成整机的装配线它在解决什么问题一个 case class 的类型类实例必须由它各个字段的类型类实例组合而成。问题在于字段类型千变万化join 怎么写才能不关心具体字段类型Magnolia 的答案是用依赖类型path-dependent type把字段的静态类型藏进Param里。CaseClass.Param内部定义了一个type PType它精确地等于该字段的类型因此param.typeclass返回的正是Typeclass[PType]param.deref(value)返回的正是PType——全程类型安全无需asInstanceOf介入你的业务代码。一步步如何实现编译器为 case class 生成Mirror.ProductOf其中MirroredElemLabels和MirroredElemTypes两个元组分别保存字段名与字段类型CaseClassDerivation.fromMirror把它们逐层展开为每个字段构造一个Param见core/src/main/scala/magnolia1/impl.scala你写的join拿到这组Param逐个取typeclass并用deref取值把这些子实例的结果拼起来得到整个 case class 的实例。关键代码逐行解读以examples/src/main/scala/magnolia1/examples/eq.scala中的Eq为例def joinT: Eq[T] (v1, v2) ctx.params.forall { p // 1. 遍历所有字段 p.typeclass.equal(p.deref(v1), p.deref(v2)) // 2. 用字段类型类比较两对象的同名字段 }第 1 行ctx.params是IArray[Param]每个Param知道自己的label、index以及它自己类型的Eq实例第 2 行p.deref(v1)从对象里取出该字段值p.typeclass.equal调用字段类型的比较逻辑。这里不需要 switch因为p.typeclass的类型是Eq[p.PType]编译器早已替我们匹配好。deref的实现藏在core/src/main/scala/magnolia1/interface.scala的Param.apply里本质只有一行def deref(value: T): P value.asInstanceOf[Product].productElement(idx).asInstanceOf[P]通过productElement(idx)按索引取值这也是为什么Param要记录index——它对应构造器参数的位置。反向装配construct 与 rawConstructjoin是拆开取值自然还有它的镜像操作——从字段值拼回对象。CaseClass提供了construct按字段类型构造和rawConstruct按任意值序列构造。看examples/.../patch.scala中Patcher的用法val effectiveFields ctx.params.zip(fieldValues).map { (param, x) if (x.asInstanceOf[AnyRef] ne null) x else param.deref(value) // null 则保留原值 } ctx.rawConstruct(effectiveFields) // 用处理后的字段序列重建对象decode.scala则是用construct结合默认值填充缺失字段的典型我们在进阶实战里还会见到它。小结join的魔法在于Param把字段的静态类型具象化为可编程的PType让组合逻辑与具体字段类型解耦construct/rawConstruct补全了反向装配能力让解码、打补丁这类需求也有了统一的抓手。核心机制二split——按实际类型分诊的和类型处理器它在解决什么问题join的输入是确定的字段集合但密封特质有个本质难点编译期知道有哪些子类运行期却不知道值到底是哪一个。这就像一个分诊台——就诊单上写着病人可能是内科或外科但必须看到人才能分诊。一步步如何实现编译器为密封特质生成Mirror.SumOf其MirroredElemTypes列出所有子类型SealedTraitDerivation.sealedTraitFromMirror为每个子类型构造一个Subtype其中携带两个关键函数isType判断值是否是该子类和asType把值安全转换为该子类类型你写的split通过ctx.choose(value)把运行时判断交给框架choose在core/src/main/scala/magnolia1/interface.scala里对subtypes数组做线性扫描找到第一个cast.isDefinedAt(value)的子类型并回调。关键代码逐行解读eq.scala中的splitoverride def splitT: Eq[T] (v1, v2) ctx.choose(v1) { sub // 1. 根据 v1 的实际类型分诊 sub.typeclass.equal(sub.value, sub.cast(v2)) // 2. 把 v2 转成同一子类型后比较 }第 1 行choose遍历ctx.subtypesSubtype本身就是一个PartialFunction——isDefinedAt(t)调用isType(t)做isInstanceOf判断第 2 行命中后sub.value是S T类型子类型与父类型的交集类型sub.cast(v2)对第二个值做同样的窄化保证两侧类型一致比较才合法。再看csv.scala里更简洁的写法def splitA: Csv[A] a ctx.choose(a) { sub sub.typeclass(sub.value) }子类型实例的懒加载细心的读者会发现subtypesFromMirrorStepimpl.scala里子类型的类型类不是立即求值的而是包在CallByNeed.createLazy(tc)里。这是刻意的性能设计一个密封特质可能有几十个子类型但一次比较只用到其中一个。CallByNeed保证实例只计算一次且计算完立刻把内部eval引用置空避免闭包长期持有外层作用域。小结split把运行期类型判断抽象成choosecast类型类作者只需写分到某个子类后怎么办分发细节由框架线性扫描完成懒加载则让多子类型场景的开销趋近于零。核心机制三derivedMirror——编译期看形状下菜碟它在解决什么问题join和split各自只会处理一种形状但调用方拿到一个类型时并不知道它属于哪种。需要一个编译期中枢根据Mirror的种类把任务分发给join或split。关键代码逐行解读core/src/main/scala/magnolia1/magnolia.scala中Derivation的入口inline def derivedMirrorA: Typeclass[A] inline mirror match case sum: Mirror.SumOf[A] derivedMirrorSumA // 和类型 → split case product: Mirror.ProductOf[A] derivedMirrorProductA // 产品类型 → joininline mirror match不是运行时分支——它在编译期就确定该走哪条路。Mirror.SumOf与Mirror.ProductOf的匹配在宏展开阶段完成因此最终生成的代码里根本没有这个分支零运行时开销。而paramsFromMapsimpl.scala的递归展开更见功底它用inline erasedValue[(Labels, Params)] match按 16、4、1 的步长分块展开元组每步直接内联生成 16 个字段的Param构造代码。这么做的原因是编译器对嵌套 inline 的深度有上限分块展开能显著提升单类型可支持的字段/子类数量上限。每个字段的类型类通过summonInline[Typeclass[p]]递归获取从而形成字段本身又是个 case class → 继续派生的自然递归。递归与互递归的支撑正因为derivedMirror在需要时才会去派生字段类型Tree这种自指类型才能成立派生Node时遇到字段类型Tree又回到derivedMirror[Tree]无限递归的风险则靠同一个实例只求值一次的CallByNeed与 Scala 的惰性机制化解。小结derivedMirror是整条流水线的调度中枢inline关键字让看形状下菜碟发生在编译期既保证了零开销也让递归派生成为顺理成章的副产品。容易踩的坑与边界情况坑一递归类型必须显式绑定 given。对递归结构只写derived而不赋给变量编译器可能无法在自身定义处找到已推导的实例。正确写法是显式声明例如given instance: SemiPrint[Recursive] SemiPrint.derivedsemiauto.scala中就有完整示范。坑二默认参数值依赖-Yretain-trees。macro.scala的defaultValue宏要从构造器默认方法的语法树里提取表达式推荐编译时开启-Yretain-trees否则某些场景下默认值解析会退化为尽力而为。坑三序列化问题。派生出的实例如果是 lambda 闭包会引用外层作用域若外层不可序列化序列化整个类型类实例就会失败。Magnolia 的应对是在内部使用SerializableFunction0这类可序列化函数见impl.scala开头的注释CallByNeed.createLazy也专为序列化场景设计。坑四全自动与半自动的取舍。AutoDerivation提供autoDerived在作用域内自动生效但多个候选实例可能引发歧义Derivation只提供derived需要你显式写derives或given ... X.derived可控性更强。没有特殊理由时给第三方类型类写派生优先用半自动模式避免污染隐式作用域。坑五性能认知。choose是线性扫描子类型数量巨大且是热路径时需留意但每个子类型实例只构造一次且eval会置空释放总体开销在可接受范围内。进阶实战让装配线和分诊台协同工作需求设计一个Config类型要求一条语句同时得到人类可读的打印和从字符串回读两种能力且缺失字段用构造器默认值兜底。代码精简自examples/的思路import magnolia1.* trait Codec[T]: def show(t: T): String def parse(s: String): T object Codec extends Derivation[Codec]: // join逐字段输出并回读缺字段用默认值 def joinT: Codec[T] new Codec[T]: def show(t: T): String ctx.params.map(p s${p.label}${p.typeclass.show(p.deref(t))}) .mkString(s${ctx.typeInfo.short}(, ,, )) def parse(s: String): T val kv s.dropWhile(_ ! ().tail.init.split(,).map(_.split(, 2)).map(a a(0) - a(1)).toMap ctx.construct { p // 反向装配 kv.get(p.label).map(p.typeclass.parse) .orElse(p.default) // 默认值兜底 .getOrElse(sys.error(smissing ${p.label})) } // split按类型名前缀分诊 def splitT: Codec[T] new Codec[T]: def show(t: T): String ctx.choose(t)(sub sub.typeclass.show(sub.value)) def parse(s: String): T val name s.takeWhile(_ ! () ctx.subtypes.find(_.typeInfo.full.endsWith(name)).get.typeclass.parse(s) given Codec[Int] new Codec[Int] { def show(t: Int) t.toString; def parse(s: String) s.toInt } given Codec[String] new Codec[String] { def show(t: String) t; def parse(s: String) s } // 被测模型sealed trait和类型 case class产品类型 默认值 enum Device derives Codec: case Desktop(cpu: String) sealed trait Notify derives Codec case class Config(host: String, port: Int 8080, notify: Notify) derives Codec case class Email(to: String) extends Notify case class Pager(dev: Device) extends Notify main def demo(): Unit val cfg Config(127.0.0.1, notify Pager(Device.Desktop(i9))) val s summon[Codec[Config]].show(cfg) // 打印 val back summon[Codec[Config]].parse(s) // 回读 println(s) println(back cfg)运行结果Config(host127.0.0.1, port8080, notifyPager(devDesktop(cpui9))) true这里的一鱼两吃正是机制协同的体现Codec的split用choose完成和类型分诊join用construct反向装配用p.default读取构造器默认值port未提供时自动落到 8080而Device、Notify、Config三层结构的递归派生由derivedMirror自动完成全程没有手写一行嵌套逻辑。若把Derivation换成AutoDerivation连derives Codec都可以省掉。总结与延伸阅读回头看Magnolia 的全部精巧之处可以浓缩为三条结论形状与策略分离Mirror负责提供形状CaseClass/SealedTrait负责封装形状join/split负责消费形状——层次清晰各司其职编译期尽力运行期求精inline让分支与元组展开发生在编译期运行期只有必要的元数据读取与一次性的懒加载计算两个配方通吃所有 ADT任意复杂类型无非是产品类型递归组合与和类型运行时分发这两种配方的嵌套这正是通用性之所在。想继续深入推荐按下面顺序阅读源码核心入口core/src/main/scala/magnolia1/magnolia.scala重点看Derivation、AutoDerivation与CommonDerivation的继承关系元数据实现core/src/main/scala/magnolia1/interface.scalaParam.deref、Subtype.cast、CallByNeed与core/src/main/scala/magnolia1/impl.scala镜像到元数据的转换注解与宏core/src/main/scala/magnolia1/macro.scala展示了注解收集、默认值提取等旁路信息如何进入派生体系最佳范本examples/src/main/scala/magnolia1/examples/下每个文件都是一个独立类型类的完整派生eq、csv、decode、default、patch、show几乎覆盖了你能遇到的所有组合模式递归与序列化的边界行为可对照test/src/test/scala/magnolia1/tests/下的测试用例验证。想亲自上手只需克隆仓库后直接编译示例git clone https://gitcode.com/gh_mirrors/ma/magnolia类型类自动派生不是魔法而是一套设计精良的形状 → 策略管线。理解了join、split和derivedMirror这三个齿轮如何咬合你就能为自己项目的任意类型类写出同样优雅的通用派生。【免费下载链接】magnoliaEasy, fast, transparent generic derivation of typeclass instances项目地址: https://gitcode.com/gh_mirrors/ma/magnolia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
一文读懂 Magnolia：深度解析类型类自动派生的实现原理
一文读懂 Magnolia深度解析类型类自动派生的实现原理【免费下载链接】magnoliaEasy, fast, transparent generic derivation of typeclass instances项目地址: https://gitcode.com/gh_mirrors/ma/magnolia接手一个已有三年历史的 Scala 项目时你可能遇到过这样的场景为了让三个嵌套的case class和一个密封特质支持比较与输出你在两个文件里手写了几百行Eq、Show样板代码。而 Magnolia 正是为消灭这种重复劳动而生的——它通过join与split两个核心方法在编译期为任意产品类型与和类型自动生成类型类实例让你从复制粘贴中彻底解放出来。一句话概括 Magnolia它把类型的形状信息有几个字段、有哪些子类和类型类的组合策略彻底分离。形状信息由编译器提供组合策略由你只写一次剩下的递归与分发全部自动完成。下面这张图先帮你建立全局印象本文的每一节都会回到它从一个让人抓狂的场景说起假设你要为下面的模型写一个相等比较器case class Address(city: String, street: String, zip: Int) case class Person(name: String, age: Int, address: Address) sealed trait Event case class Login(p: Person, at: Long) extends Event case class Logout(at: Long) extends Event手写Eq[Person]时你得取出name、age、address三个字段分别比较而比较address又要重复一遍它的三个字段更麻烦的是Event这种密封特质比较前还得先判断两个值到底是不是同一个子类。字段一多、层级一深代码量呈几何级数膨胀。Magnolia 的思路非常直白这类推导是有固定配方的。case class 的实例等于所有字段实例的组合密封特质的实例等于按实际子类选择一个实例。只要把这两个配方写一次剩下的交给编译器自动套用。这正是join与split名字的由来。为什么非要有元数据这层设计先抛个问题为什么不直接用宏生成全部代码非要先造出CaseClass、SealedTrait这些运行时对象答案是关注点分离。纯宏方案里取字段、判断子类这些底层操作和如何组合类型类的高层策略纠缠在一起每写一个新类型类都要重新和宏 API 搏斗。Magnolia 选择在中间插入一层形状元数据编译期用 Scala 3 内置的Mirror拿到类型的形状字段列表、子类型列表、类型参数运行期把这套形状封装成CaseClass/SealedTrait对象字段的取值deref、构造construct、子类判断cast都通过它们完成你写的join/split只负责如何利用这套形状完全不关心形状是怎么来的。这层设计带来三个实际好处一是类型类作者只需要理解几个直观的 API二是元数据惰性求值性能可控三是注解、默认值、重复参数这些旁路信息可以统一塞进元数据join/split拿起来就能用。核心机制一join——把零件拼成整机的装配线它在解决什么问题一个 case class 的类型类实例必须由它各个字段的类型类实例组合而成。问题在于字段类型千变万化join 怎么写才能不关心具体字段类型Magnolia 的答案是用依赖类型path-dependent type把字段的静态类型藏进Param里。CaseClass.Param内部定义了一个type PType它精确地等于该字段的类型因此param.typeclass返回的正是Typeclass[PType]param.deref(value)返回的正是PType——全程类型安全无需asInstanceOf介入你的业务代码。一步步如何实现编译器为 case class 生成Mirror.ProductOf其中MirroredElemLabels和MirroredElemTypes两个元组分别保存字段名与字段类型CaseClassDerivation.fromMirror把它们逐层展开为每个字段构造一个Param见core/src/main/scala/magnolia1/impl.scala你写的join拿到这组Param逐个取typeclass并用deref取值把这些子实例的结果拼起来得到整个 case class 的实例。关键代码逐行解读以examples/src/main/scala/magnolia1/examples/eq.scala中的Eq为例def joinT: Eq[T] (v1, v2) ctx.params.forall { p // 1. 遍历所有字段 p.typeclass.equal(p.deref(v1), p.deref(v2)) // 2. 用字段类型类比较两对象的同名字段 }第 1 行ctx.params是IArray[Param]每个Param知道自己的label、index以及它自己类型的Eq实例第 2 行p.deref(v1)从对象里取出该字段值p.typeclass.equal调用字段类型的比较逻辑。这里不需要 switch因为p.typeclass的类型是Eq[p.PType]编译器早已替我们匹配好。deref的实现藏在core/src/main/scala/magnolia1/interface.scala的Param.apply里本质只有一行def deref(value: T): P value.asInstanceOf[Product].productElement(idx).asInstanceOf[P]通过productElement(idx)按索引取值这也是为什么Param要记录index——它对应构造器参数的位置。反向装配construct 与 rawConstructjoin是拆开取值自然还有它的镜像操作——从字段值拼回对象。CaseClass提供了construct按字段类型构造和rawConstruct按任意值序列构造。看examples/.../patch.scala中Patcher的用法val effectiveFields ctx.params.zip(fieldValues).map { (param, x) if (x.asInstanceOf[AnyRef] ne null) x else param.deref(value) // null 则保留原值 } ctx.rawConstruct(effectiveFields) // 用处理后的字段序列重建对象decode.scala则是用construct结合默认值填充缺失字段的典型我们在进阶实战里还会见到它。小结join的魔法在于Param把字段的静态类型具象化为可编程的PType让组合逻辑与具体字段类型解耦construct/rawConstruct补全了反向装配能力让解码、打补丁这类需求也有了统一的抓手。核心机制二split——按实际类型分诊的和类型处理器它在解决什么问题join的输入是确定的字段集合但密封特质有个本质难点编译期知道有哪些子类运行期却不知道值到底是哪一个。这就像一个分诊台——就诊单上写着病人可能是内科或外科但必须看到人才能分诊。一步步如何实现编译器为密封特质生成Mirror.SumOf其MirroredElemTypes列出所有子类型SealedTraitDerivation.sealedTraitFromMirror为每个子类型构造一个Subtype其中携带两个关键函数isType判断值是否是该子类和asType把值安全转换为该子类类型你写的split通过ctx.choose(value)把运行时判断交给框架choose在core/src/main/scala/magnolia1/interface.scala里对subtypes数组做线性扫描找到第一个cast.isDefinedAt(value)的子类型并回调。关键代码逐行解读eq.scala中的splitoverride def splitT: Eq[T] (v1, v2) ctx.choose(v1) { sub // 1. 根据 v1 的实际类型分诊 sub.typeclass.equal(sub.value, sub.cast(v2)) // 2. 把 v2 转成同一子类型后比较 }第 1 行choose遍历ctx.subtypesSubtype本身就是一个PartialFunction——isDefinedAt(t)调用isType(t)做isInstanceOf判断第 2 行命中后sub.value是S T类型子类型与父类型的交集类型sub.cast(v2)对第二个值做同样的窄化保证两侧类型一致比较才合法。再看csv.scala里更简洁的写法def splitA: Csv[A] a ctx.choose(a) { sub sub.typeclass(sub.value) }子类型实例的懒加载细心的读者会发现subtypesFromMirrorStepimpl.scala里子类型的类型类不是立即求值的而是包在CallByNeed.createLazy(tc)里。这是刻意的性能设计一个密封特质可能有几十个子类型但一次比较只用到其中一个。CallByNeed保证实例只计算一次且计算完立刻把内部eval引用置空避免闭包长期持有外层作用域。小结split把运行期类型判断抽象成choosecast类型类作者只需写分到某个子类后怎么办分发细节由框架线性扫描完成懒加载则让多子类型场景的开销趋近于零。核心机制三derivedMirror——编译期看形状下菜碟它在解决什么问题join和split各自只会处理一种形状但调用方拿到一个类型时并不知道它属于哪种。需要一个编译期中枢根据Mirror的种类把任务分发给join或split。关键代码逐行解读core/src/main/scala/magnolia1/magnolia.scala中Derivation的入口inline def derivedMirrorA: Typeclass[A] inline mirror match case sum: Mirror.SumOf[A] derivedMirrorSumA // 和类型 → split case product: Mirror.ProductOf[A] derivedMirrorProductA // 产品类型 → joininline mirror match不是运行时分支——它在编译期就确定该走哪条路。Mirror.SumOf与Mirror.ProductOf的匹配在宏展开阶段完成因此最终生成的代码里根本没有这个分支零运行时开销。而paramsFromMapsimpl.scala的递归展开更见功底它用inline erasedValue[(Labels, Params)] match按 16、4、1 的步长分块展开元组每步直接内联生成 16 个字段的Param构造代码。这么做的原因是编译器对嵌套 inline 的深度有上限分块展开能显著提升单类型可支持的字段/子类数量上限。每个字段的类型类通过summonInline[Typeclass[p]]递归获取从而形成字段本身又是个 case class → 继续派生的自然递归。递归与互递归的支撑正因为derivedMirror在需要时才会去派生字段类型Tree这种自指类型才能成立派生Node时遇到字段类型Tree又回到derivedMirror[Tree]无限递归的风险则靠同一个实例只求值一次的CallByNeed与 Scala 的惰性机制化解。小结derivedMirror是整条流水线的调度中枢inline关键字让看形状下菜碟发生在编译期既保证了零开销也让递归派生成为顺理成章的副产品。容易踩的坑与边界情况坑一递归类型必须显式绑定 given。对递归结构只写derived而不赋给变量编译器可能无法在自身定义处找到已推导的实例。正确写法是显式声明例如given instance: SemiPrint[Recursive] SemiPrint.derivedsemiauto.scala中就有完整示范。坑二默认参数值依赖-Yretain-trees。macro.scala的defaultValue宏要从构造器默认方法的语法树里提取表达式推荐编译时开启-Yretain-trees否则某些场景下默认值解析会退化为尽力而为。坑三序列化问题。派生出的实例如果是 lambda 闭包会引用外层作用域若外层不可序列化序列化整个类型类实例就会失败。Magnolia 的应对是在内部使用SerializableFunction0这类可序列化函数见impl.scala开头的注释CallByNeed.createLazy也专为序列化场景设计。坑四全自动与半自动的取舍。AutoDerivation提供autoDerived在作用域内自动生效但多个候选实例可能引发歧义Derivation只提供derived需要你显式写derives或given ... X.derived可控性更强。没有特殊理由时给第三方类型类写派生优先用半自动模式避免污染隐式作用域。坑五性能认知。choose是线性扫描子类型数量巨大且是热路径时需留意但每个子类型实例只构造一次且eval会置空释放总体开销在可接受范围内。进阶实战让装配线和分诊台协同工作需求设计一个Config类型要求一条语句同时得到人类可读的打印和从字符串回读两种能力且缺失字段用构造器默认值兜底。代码精简自examples/的思路import magnolia1.* trait Codec[T]: def show(t: T): String def parse(s: String): T object Codec extends Derivation[Codec]: // join逐字段输出并回读缺字段用默认值 def joinT: Codec[T] new Codec[T]: def show(t: T): String ctx.params.map(p s${p.label}${p.typeclass.show(p.deref(t))}) .mkString(s${ctx.typeInfo.short}(, ,, )) def parse(s: String): T val kv s.dropWhile(_ ! ().tail.init.split(,).map(_.split(, 2)).map(a a(0) - a(1)).toMap ctx.construct { p // 反向装配 kv.get(p.label).map(p.typeclass.parse) .orElse(p.default) // 默认值兜底 .getOrElse(sys.error(smissing ${p.label})) } // split按类型名前缀分诊 def splitT: Codec[T] new Codec[T]: def show(t: T): String ctx.choose(t)(sub sub.typeclass.show(sub.value)) def parse(s: String): T val name s.takeWhile(_ ! () ctx.subtypes.find(_.typeInfo.full.endsWith(name)).get.typeclass.parse(s) given Codec[Int] new Codec[Int] { def show(t: Int) t.toString; def parse(s: String) s.toInt } given Codec[String] new Codec[String] { def show(t: String) t; def parse(s: String) s } // 被测模型sealed trait和类型 case class产品类型 默认值 enum Device derives Codec: case Desktop(cpu: String) sealed trait Notify derives Codec case class Config(host: String, port: Int 8080, notify: Notify) derives Codec case class Email(to: String) extends Notify case class Pager(dev: Device) extends Notify main def demo(): Unit val cfg Config(127.0.0.1, notify Pager(Device.Desktop(i9))) val s summon[Codec[Config]].show(cfg) // 打印 val back summon[Codec[Config]].parse(s) // 回读 println(s) println(back cfg)运行结果Config(host127.0.0.1, port8080, notifyPager(devDesktop(cpui9))) true这里的一鱼两吃正是机制协同的体现Codec的split用choose完成和类型分诊join用construct反向装配用p.default读取构造器默认值port未提供时自动落到 8080而Device、Notify、Config三层结构的递归派生由derivedMirror自动完成全程没有手写一行嵌套逻辑。若把Derivation换成AutoDerivation连derives Codec都可以省掉。总结与延伸阅读回头看Magnolia 的全部精巧之处可以浓缩为三条结论形状与策略分离Mirror负责提供形状CaseClass/SealedTrait负责封装形状join/split负责消费形状——层次清晰各司其职编译期尽力运行期求精inline让分支与元组展开发生在编译期运行期只有必要的元数据读取与一次性的懒加载计算两个配方通吃所有 ADT任意复杂类型无非是产品类型递归组合与和类型运行时分发这两种配方的嵌套这正是通用性之所在。想继续深入推荐按下面顺序阅读源码核心入口core/src/main/scala/magnolia1/magnolia.scala重点看Derivation、AutoDerivation与CommonDerivation的继承关系元数据实现core/src/main/scala/magnolia1/interface.scalaParam.deref、Subtype.cast、CallByNeed与core/src/main/scala/magnolia1/impl.scala镜像到元数据的转换注解与宏core/src/main/scala/magnolia1/macro.scala展示了注解收集、默认值提取等旁路信息如何进入派生体系最佳范本examples/src/main/scala/magnolia1/examples/下每个文件都是一个独立类型类的完整派生eq、csv、decode、default、patch、show几乎覆盖了你能遇到的所有组合模式递归与序列化的边界行为可对照test/src/test/scala/magnolia1/tests/下的测试用例验证。想亲自上手只需克隆仓库后直接编译示例git clone https://gitcode.com/gh_mirrors/ma/magnolia类型类自动派生不是魔法而是一套设计精良的形状 → 策略管线。理解了join、split和derivedMirror这三个齿轮如何咬合你就能为自己项目的任意类型类写出同样优雅的通用派生。【免费下载链接】magnoliaEasy, fast, transparent generic derivation of typeclass instances项目地址: https://gitcode.com/gh_mirrors/ma/magnolia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考