Satoshi Ikari

@conjikidow [こちら](https://github.com/ut-issl/s2e-core/issues/326#issuecomment-2282923335)の議論ですが、今は次のような状況です。 - 元々`namespace`は旧libraryにしかついていなかったので、今の整理も旧library関係のもの（主にmath_physics）になっている 旧library以外のもの全てにnamespaceをつけるかの議論がまず必要だと思います。 全てにnamespaceをつける利点・欠点などは整理したいですが教えてもらえると嬉しいです。 参考として、`dynamics/orbit`と`math_physics/orbit`の差としては、次のようなことを考えています。 - 前者は真値系としての実体であり後者を利用して実体化させたものである。 - 後者はあくまでいろんな人に使われる側であり、s2e-coreでは前者に使われている。ユーザーによってはこれを利用して推定系や制御系など真値系と別の`estimate/orbit`などを作る可能性もある

具体的にありがとうございます。基本的な利点・欠点の整理について、書かれている内容は同意します。あとは、程度問題で何に重きを置くかですね。 現状のaobcなどを考えて個別の事象にどう対処しているかを考えながら議論を深めたいですね。 > 例えば独自の電池を扱いたい場合，すでにcoreで Battery が定義されているため，それを継承したクラスを作ろうとしても Battery は使えない などは、`製品名にする`ことを推奨しているという気持ちです。（aobcなどは全てそう） また、これをs2e-core側で`component::battery`としても、一般性が高いままなので、ユーザーも結局`component::battery`使いたいとなる気もしています。 ユーザー側が、`my_component::battery`などにするなら、`my_battery`とするのとあまり変わらないですから難しいですね。s2e-core側を`core_component::battery`のように一般性を下げる方が良いんですかね。 `dynamics::orbit`も、ユーザーからしたら`推定器の中のdynamicsだから、dynamics::orbitと名付けたいな`というのなども十分あり得る気がしています。 この辺り、s2e-core側で良い名前空間をつけないと、`欠点にあるような労力をかけたのに、結局利点にあるようなスマートな名前衝突回避にならず、名前空間使わずに衝突回避した時と変わらない`とかになってしまいそうなのを危惧しています。 これを根本解決するには、全てを `s2e-core::hoge::fuga`のように絶対ユーザーがつけないようにするとかしか無いんですかね。

ちなみに、欠点の後方互換性と名前が長くなる件は、あまり重要視していません。 - どのみちこのMajor updateはいろんな後方互換性をなくしている - 名前が長くなる件はs2e-coreでは許容して、略語なども使わないという方針になっている

修正方針が決まれば修正自体は簡単なので、今回やってしまっても良いかなと思っています。 `s2e::ディレクトリ名` のようなルールで行くとすぐ決めて良いならそれでやってしまいます。いかがでしょうか？

では、それでPR出してみようと思います。