Felix
Felix
你所谓的Codable闪退是因为前后端类型定义不规范, 或者没正确的try-catch吧. 类型问题可以搞AnyTypeCodable自己做兼容,当然最好是前后端遵守约定. didFinishMapping没必要. 解析完成就是finish, 中间过程没必要对外抛出, 用户做些花里胡哨的操作, 反正会增加解析失败的可能. HandyJSON 的写法, 不支持定义let变量, 无法在语法层限制变量值的不可变特性, 这也是个缺陷. 数据模型建议尽可能搞成struct { let }, 对吧? iOS系统一升级就担心调整Mirror反射的实现, 就担心HandyJSON导致crash. iOS15出来时它就崩了, 不能及时修复的话, 只能自己修了指向本地分支. 100多个没close的issues赶紧都关闭了, 这是对用户最大的价值.
Codable有异常捕获啊，我哪里说会crash了，Codable我确实从没crash过，团队其他人使用这个库导致系统升级而crash，我说最好都遵守约定，这样就不会异常，更不会crash。 需求: 有一个字段需要根据其它字段计算，这不就是计算属性么？你认为struct let是小问题，约束自己就可以？其它小伙伴也是有可能误用为变量，这对团队项目其实有不小影响。 后端需要统一类型，支持多种类型这是妥协，不是兼容，退一步讲，Codable确实也是可以自定义解析过程来解决这种问题。你说难用见仁见智吧
”我大多数情况去修改模型属性时，都是希望在页面间传来传去，我本来就需要去修改它”，一般来说你不应该修改原值，这个做法是不对的。 String Int本来就不应该互转，你竟然还反问强类型带来了什么，也没必要争论下去了。
对，不应该在解析过程中互转，会丢失信息。(要不咱不骂人?)
转过后你得到了123，但你永远也得不到原值了，原值是”123.0”还是”0123”，你不知道
你只应该在自己的使用场景做自己所需的转换，你不能确定是否别的场景会使用原值做别的操作