c2af6c9987
- Add comprehensive design discussion with Gemini about unified BoxFactory - Define Phase 9.78 implementation plan with 6 sub-phases (9.78a-f) - Include clone_box/share_box semantics clarification and fixes - Update CURRENT_TASK.md with specific misimplementation details - Archive Gemini's deep technical analysis endorsing the approach 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
145 lines
4.9 KiB
Markdown
145 lines
4.9 KiB
Markdown
# 統合BoxFactory設計議論 - Geminiとの深い考察（2025年1月）
|
||
|
||
## 概要
|
||
Nyashプログラミング言語のBox生成システムを統一する設計について、Geminiと深い技術的議論を行った記録。
|
||
|
||
## 背景と問題点
|
||
|
||
### 現在の問題
|
||
`src/interpreter/objects.rs`内でBox生成が3つの完全に異なるフローに分かれている：
|
||
|
||
1. **ビルトインBox**（StringBox, IntegerBox等）
|
||
- 600行以上の巨大match文で直接生成
|
||
- 各Boxごとに個別のコード
|
||
- 新しいビルトインBox追加時に手動で追加必要
|
||
|
||
2. **ユーザー定義Box**
|
||
- InstanceBox経由で生成
|
||
- 継承、フィールド、メソッドを動的に解決
|
||
- birth/finiライフサイクル完全対応
|
||
|
||
3. **プラグインBox**（FileBox等）
|
||
- BoxFactoryRegistry経由で生成（v2システム）
|
||
- 動的ロード、FFI経由
|
||
- nyash.tomlで設定
|
||
|
||
## 統合BoxFactoryアーキテクチャ提案
|
||
|
||
```rust
|
||
// 統一インターフェース
|
||
trait BoxFactory: Send + Sync {
|
||
fn create_box(&self, name: &str, args: &[Box<dyn NyashBox>]) -> Result<Box<dyn NyashBox>, RuntimeError>;
|
||
fn is_available(&self) -> bool;
|
||
fn box_types(&self) -> Vec<&str>;
|
||
fn supports_birth(&self) -> bool { true } // birth/finiサポート
|
||
}
|
||
|
||
// 統合レジストリ
|
||
struct UnifiedBoxRegistry {
|
||
factories: Vec<Box<dyn BoxFactory>>,
|
||
}
|
||
```
|
||
|
||
## Geminiの深い分析と結論
|
||
|
||
### 1. シンプルさについて
|
||
**結論：長期的かつ概念的に、コードは間違いなくシンプルになる**
|
||
|
||
- 現在の「暗黙知の複雑性」から「構造化されたシンプルさ」へ
|
||
- `execute_new`関数が数行のクリーンなコードに
|
||
- 単一の抽象概念により予測可能性が向上
|
||
|
||
### 2. 保守性について
|
||
**結論：圧倒的に正しい選択**
|
||
|
||
- 新Box追加：巨大match文編集 → HashMap1行追加
|
||
- コンフリクトの激減
|
||
- 関心事のきれいな分離
|
||
- コンパイル時チェックの喪失はテスト1つでカバー可能
|
||
|
||
### 3. birth/finiライフサイクル
|
||
**結論：クリーンな責務分離が最良**
|
||
|
||
- `birth`はFactoryの責務（`create_box`メソッド）
|
||
- `fini`はBoxインスタンス自身の責務
|
||
- 「生み出す」と「死ぬ」の明確な分離
|
||
|
||
### 4. パフォーマンス影響
|
||
**結論：無視できるほど軽微**
|
||
|
||
- 理論上の差：数ナノ秒〜数十ナノ秒
|
||
- Box生成処理全体から見れば測定誤差範囲
|
||
- 保守性向上のメリットがはるかに大きい
|
||
|
||
### 5. Nyash哲学との整合性
|
||
**結論：むしろ哲学をより強化する設計**
|
||
|
||
- "Everything is Box"をコードレベルで体現
|
||
- すべてのBoxが統一的に扱われる
|
||
- より高度なレベルでの「明示性」を実現
|
||
|
||
## 追加の改善案：マクロによる宣言的登録
|
||
|
||
```rust
|
||
macro_rules! register_builtins {
|
||
($registry:expr, $($box_name:literal => $creator_fn:path),* $(,)?) => {
|
||
$(
|
||
$registry.add_builtin($box_name, Box::new($creator_fn));
|
||
)*
|
||
};
|
||
}
|
||
|
||
// 使用例
|
||
register_builtins!(factory,
|
||
"StringBox" => StringBox::nyash_create,
|
||
"IntegerBox" => IntegerBox::nyash_create,
|
||
"BoolBox" => BoolBox::nyash_create,
|
||
"ArrayBox" => ArrayBox::nyash_create,
|
||
// ...
|
||
);
|
||
```
|
||
|
||
## 段階的移行プラン
|
||
|
||
1. **Step 1: 基盤の構築**
|
||
- BoxFactoryトレイト実装
|
||
- 各Factory構造体実装
|
||
- UnifiedBoxRegistry実装
|
||
|
||
2. **Step 2: ビルトインBoxの移行**
|
||
- match文のロジックを各Boxのcreate関数に抽出
|
||
- BuiltinBoxFactoryに登録
|
||
- フォールバック付きで段階移行
|
||
|
||
3. **Step 3: プラグインBoxの移行**
|
||
- PluginBoxFactory実装
|
||
- 既存のBoxFactoryRegistryをラップ
|
||
|
||
4. **Step 4: ユーザー定義Boxの移行**
|
||
- UserDefinedBoxFactory実装
|
||
- Interpreterへの参照を保持
|
||
|
||
5. **Step 5: クリーンアップ**
|
||
- テストで完全移行を確認
|
||
- 古いコード（巨大match文等）を完全削除
|
||
|
||
## Geminiの最終評価
|
||
|
||
> 「あなたの提案は、Nyash言語の内部品質を劇的に向上させる、非常に価値のあるリファクタリングです。抽象化は複雑さを増すためのものではなく、本質的でない複雑さを隠蔽し、一貫したルールを適用するためにあります。このケースは、まさにその好例です。」
|
||
|
||
> 「パフォーマンスへの懸念は不要であり、保守性、拡張性、そして言語哲学との整合性といった面で計り知れないメリットがあります。」
|
||
|
||
## 結論
|
||
|
||
統合BoxFactoryアーキテクチャは：
|
||
- Nyashの哲学を強化
|
||
- コードの保守性を劇的に向上
|
||
- 将来の拡張性を確保
|
||
- パフォーマンスへの影響は無視できるレベル
|
||
|
||
この設計は実装すべき価値のある改善である。
|
||
|
||
---
|
||
|
||
*記録日: 2025年1月19日*
|
||
*議論参加者: Claude (Anthropic) & Gemini (Google)* |