C2A 用語のリネーム: v4.0.0 まで

[meltingrabbit]

詳細 (v4.0.0まで)

C2A 用語がわかりにくいので，一般的な CS 用語に変換していく
これに伴い，ディレクトリ構造も変更する

• IF Wrapper -> HAL: Rename component: IfWrapper -> hal #21
  • rename & refactor: IF list -> DS handler registry  #22
• Driver -> Component Driver: CDRV: Rename Driver -> Component Driver #146
• Driver Inctance -> Component Service: CS: Rename driver_instances -> component_service #143
• eb90_frame_for_driver_super.h などを cds_eb90_frame.h へ，接頭辞renameする #148

詳細 (v4.0.0以降)

• C2A 用語のリネーム: v5.0.0 まで #151 に分離

close条件

上のチェックリストが完了したら

備考

過去の議論: ut-issl/c2a-core#454

[meltingrabbit]

うーん，2文字は結構衝突するので，name space 切る略語は3, 4文字ぐらいにしたさがあるな．．．

[sksat]

C2A は CS 文脈の言葉で雑に表現すると C2A プロトコルのフレームワークであり，libOS な microkernel 的物体でもあるので，それに即した命名・分割・概念の借用を行っていきたい．その観点から考えると，Application は microkernel の server が一番近い．

[sksat]

まあ server と呼ぶとそれ以外の普通の "サーバー" と被るし，別に microkernel 文脈でもディレクトリ名を server にしてがちみたいな慣習があるわけでもないので，service ぐらいでいいか．そうすると component service とかの案とも整合が取れる．問題はかなり色々なものがこの枠組みに乗っていて，乗っていること自体はよいのだがそのカテゴリの区別が明確でないこと．

[sksat]

DriverSuper はフレームの encode/decode を扱っているやつ，として Framing にする（後で encoder とか decoder みたいな名前で分割するなどはありえるかもしれない）．略称は FRM

[meltingrabbit]

framing はありかもしれんな．packetつくりはしてないわけだし（たまにしてるけど）

[sksat]

たまにしちゃってるのは後から追い出しましょう

[meltingrabbit]

core/Driversは

core/framing/framing.c
core/framing/framing_common_tlm_cmd_packet.c
core/framing/data_link_layer_definition.h

に．
そして関数名も

EB90_PACKET_get_version_from_dssc
→
FRM_EB90_PACKET_get_version

[sksat]

DriverSuper は元の目的は Driver の抽象化で，実際そのように使われてもいて，しかし8割方の責務はフレームの encode/decode の共通化，というような状態になっている．また，DriverSuper のメンバ関数的実装が何故か別のディレクトリ（Driver/Protocol）にあって分かりにくい．

[sksat]

そして，v4 での大規模な rename の目的は，既存の慣れによる C2A 用語でのコミュニケーションを破壊してでも，一般的な CS 用語に寄せて新規参入者に対する分かりにくさを低減すると共に，責務に対して明らかな命名をすることで現在でもよく発生しているミスリードを減らすこと．最も breaking change なのはここであり，だからこそ現状 minor update でも breaking change をしている c2a-core でも major update としている．

また，主目的は人間の認識に対する breaking change であるからこそ，それ以外の変更はできるだけしていない．つまり，多くの変更はあくまで機械的な rename であって，実装の互換性はできるだけ保っている．そのため，ほとんどの変更は各 C2A user で migration script による移行が可能となっている．

[sksat]

ここで，DriverSuper -> Framing の rename は実装の責務を明らかにするための命名変更となる．が，DriverSuper 自体の実装の主な責務は Framing の名前に相当するものであるものの，これの感覚的な役割はやはり各 Driver のスーパークラス的なモノであるという別の事実も存在する．それを踏まえると，仮に DriverSuper -> Framing の rename をするのであれば，この「継承関係」も同時に破壊する必要がある．そこまでのリファクタを実施するのは人間からの認知的にも実装的にも breaking change が大きすぎ，v4 の目的もスケジュールも逸脱してしまう．

その上で，Driver や DriverSuper 関連でやるべきことを優先度順に並べると，以下のようになると思われる．

1. c2a-core/Driver のディレクトリを snake_case にする: ディレクトリ名の CamelCase をやめたい #10
2. 現 Driver を ComponentDriver に，現 DriverInstance を ComponentService に rename する

• "driver" という語は何を drive するのかまったくわからないし，C2A 以外でも使われる語なので，（特に口頭で）雑に「ドライバー」と言われた時にとても confusing であり，この rename の優先度はかなり高い

3. 現 DriverSuper の実装が行っているフレームの encode/decode を framing ライブラリとして分割する
4. 現 DriverSuper - Driver の「継承関係」をリファクタする

このうち，1,2 はこれまでの v4 rename と同じように実装可能であり，かつ，優先度が高い．そのため，v4.0.0 では 1,2 までを行うこととしたい．

[meltingrabbit]

極めてわかりやすい整理なので，違和感ないです．では1,2お願いしたいです

[sksat]

v4.0.0 以降での rename は #151 でやる