Conversation
|
とりあえず分離したけど、model.pyの方の型はBaseModelとかFieldとかなくして、dataclassにしたほうが良さそう |
Pull Request Test Coverage Report for Build 1642267046
💛 - Coveralls |
ea8d8fa to
7642e52
Compare
|
とりあえずデータ型を分離して、変換関数を実装しました
|
たしかに変更量は結構大きめですが、取り込んじゃいましょう!! ただもうちょっと実装の負担を減らせると嬉しいかなと思いました。
dataclassにしちゃったほうが良いと思います。
full_context_labelはOpenJTalkに引っ張られる仕様なため、エンジン用とはまた変わってきそうな気もします。 |
~engineだと何の型にするのか想像しにくいのではないでしょうか? model.py にあるのだからto_model,from_modelにするか、modelが紛らわしいのならmodel.pyの名前を例えばdomain.pyにし、to_domain,from_domainにしたほうが良さそうに感じました。
👍
このPRではやりませんが、残すのであればそれらの型名にプレフィックスでOpenJTalkをつけたほうが良さそうですね。似たような型があるので混同しそうです |
例えば |
…o_engineとして実装した 若干名前に違和感はあるものの、特段こだわりがあったわけではないのでとりあえず修正 List系はあってもなくても書く量が変わらないのとクラスメソッドとして生えていたら不自然だったので削除した
…o_engineとして実装した 若干名前に違和感はあるものの、特段こだわりがあったわけではないのでとりあえず修正 cyclic importになったのでもとの実装は削除した List系はあってもなくても書く量が変わらないのとクラスメソッドとして生えていたら不自然だったので削除した
f022063 to
f0ee782
Compare
|
from_engine,to_engineメソッドを各クラスに実装しましたcyclic importになったのでもとの実装は消しました |
…o_engineとして実装した cyclic importになったのでもとの実装は削除した List系はあってもなくても書く量が変わらないのとクラスメソッドとして生えていたら不自然だったので削除した
17f9c31 to
8cf983d
Compare
Hiroshiba
left a comment
There was a problem hiding this comment.
大丈夫そうです!
後世に伝えるにあたってちょっと変えれそうなところをコメントしてみました。
Co-authored-by: Hiroshiba <hihokaruta@gmail.com>
これでわからなければコメントを追加する必要あり
This reverts commit ff00ad6.
内容
APIで返す型と内部で使う型が同じだとフィールドをおいそれと変えることが難しいので、型を分離する
Pros
APIのデータ構造を変えることなく内部で型を好きに変えることができる
Cons
その他
full_context_label.pyにある型もmodel.pyに統合してしまいたいが、変更量次第?