My suggestion: Use Codable instead it

[kodboy]

使用Codable

[likeSo]

价值？有没有价值难道用户不懂？苹果的api有多难用你是不知道吗？万倍好用是谁得出来的？你知道Codable很容易闪退吗？Codable没有didFinishMapping方法，Codable需要自己写decoder，Codable对字段类型强依赖，假设某个字段跟后端对应不上就闪退了。是Model.deserialize()好用还是try JSONDecoder().decode()好用？到底谁的bug多？。。。

[kodboy]

你所谓的Codable闪退是因为前后端类型定义不规范, 或者没正确的try-catch吧. 类型问题可以搞AnyTypeCodable自己做兼容,当然最好是前后端遵守约定. didFinishMapping没必要. 解析完成就是finish, 中间过程没必要对外抛出, 用户做些花里胡哨的操作, 反正会增加解析失败的可能. HandyJSON 的写法, 不支持定义let变量, 无法在语法层限制变量值的不可变特性, 这也是个缺陷. 数据模型建议尽可能搞成struct { let }, 对吧? iOS系统一升级就担心调整Mirror反射的实现, 就担心HandyJSON导致crash. iOS15出来时它就崩了, 不能及时修复的话, 只能自己修了指向本地分支. 100多个没close的issues赶紧都关闭了, 这是对用户最大的价值.

[likeSo]

遵守约定？你觉得这四个字能约束的住谁？而且一个字段变动就能导致你客户端闪退，这合适吗？难道要把所有字段标记为可选吗？ didFinishMapping为什么没必要？假设我有一个通用模型，我有一个字段需要根据其他字段来定，难道我要在模型外面写？内部的逻辑放到外面去好玩吗是？另，并没有遇到过因为didFinishMapping而导致解析失败... struct和let这点我承认，有时候是不希望模型字段从外界改变，但这点小问题也叫问题吗，约束自己比约束后端简单多了吧？ 确实会担心新版本crash，我也想换，但是说实话没找到一个能打的... mapping方法处理自定义解析，didFinishMapping方法处理业务模型字段逻辑，目前就发现一个ObjectMappery有点类似，但它需要自己写mapper方法，还是不够好用... 所以价值不价值的，谁用谁清楚...

[kodboy]

Codable有异常捕获啊，我哪里说会crash了，Codable我确实从没crash过，团队其他人使用这个库导致系统升级而crash，我说最好都遵守约定，这样就不会异常，更不会crash。 需求: 有一个字段需要根据其它字段计算，这不就是计算属性么？你认为struct let是小问题，约束自己就可以？其它小伙伴也是有可能误用为变量，这对团队项目其实有不小影响。 后端需要统一类型，支持多种类型这是妥协，不是兼容，退一步讲，Codable确实也是可以自定义解析过程来解决这种问题。你说难用见仁见智吧

[likeSo]

最好遵守约定，这句话跟没说其实是一样的，没有人会在意你一个前端的想法，指不定谁改了个字段就导致客户端出问题了。 并不是计算属性，计算属性你每次获取都需要重新计算，如果你把它放到cell里面，那么这个问题更加严重。而didFinishMapping只需要在解析完毕之后执行一次即可。 你说的struct let只能算是一个对强迫症不友好的情况，我大多数情况去修改模型属性时，都是希望在页面间传来传去，我本来就需要去修改它。 使用Codable，你不得不处理与后端的字段对照的问题，要处理解析失败的问题。使用HandyJSON，你只需要关心某字段如果后端没给你时，它的默认值是什么即可，如果不是因为反射的问题，那么它显然比其他解析框架好用多了。 至于类型严格，Swift类型严格，可是这带来了什么？CGFloat和Int都需要自己显式转换？String截取都需要写一堆代码？还是Optional<Optional>的问题？后端发现你String和Int都不能互转，会不会觉得你是废物？😂😂 所以你这Codable的“万倍”强于HandyJSON，到底强在哪呢😂

[kodboy]

”我大多数情况去修改模型属性时，都是希望在页面间传来传去，我本来就需要去修改它”，一般来说你不应该修改原值，这个做法是不对的。 String Int本来就不应该互转，你竟然还反问强类型带来了什么，也没必要争论下去了。

[kodboy]

对，不应该在解析过程中互转，会丢失信息。(要不咱不骂人?)

[kodboy]

转过后你得到了123，但你永远也得不到原值了，原值是”123.0”还是”0123”，你不知道

[kodboy]

你只应该在自己的使用场景做自己所需的转换，你不能确定是否别的场景会使用原值做别的操作

[likeSo]

"123"和123不应该互转？你是没用过JSON解析框架？或者是没有使用过其他语言？你在闭包里面多写两行代码，Xcode就识别不出来返回值类型了...强类型语言是只有Swift一家吗？为什么Java，TS甚至是Dart都没有Swift这些毛病？ 至于修改原值，你猜数据模型是用来干啥的，我在界面上操作了某个字段，难道我不去更新数据模型内部的字段吗？是不是有点过于理想化了？ 至于丢失信息，丢失信息是丢失信息的问题，是另一个问题，很多时候需要使用String来传递数字，来解决精度问题。 至于所谓0123，你不觉得你在强行圆场吗？假设我某个字段用来展示价格，那我知道原值的0123用来干嘛，我计算的时候用0123用来干嘛你告诉我 至于别的场景，这难道不是didFinishMapping的用武之地吗？你说的这个场景，用Codable来做似乎只会更麻烦...

[kodboy]

到此为止

[RITL]

#466 作者现在都不再推荐使用了..

[likeSo]

这个当时看到了，新项目不再使用，但是还有那么多老项目啊...作者因为没有精力维护所以不再推荐使用，我觉得这个跟易用性是不冲突的 我也想过换掉，可惜没找到一个能打的...

[RITL]

唉，只能希望 iOS 更新的时候 不要做太多变动了，要是在崩溃，真心吃不大消的..

[ghost]

这个当时看到了，新项目不再使用，但是还有那么多老项目啊...作者因为没有精力维护所以不再推荐使用，我觉得这个跟易用性是不冲突的 我也想过换掉，可惜没找到一个能打的...

KaKaJson 还能用不

[intsig171]

可以考虑使用 SmartCodable，https://github.com/intsig171/SmartCodable 。 基于系统Codable解析能力，针对 字段缺失/字段类型不匹配/字段值为null的情况 进行了兼容。并且提供了didFinishMapping方法。