hakorune/local_tests/box_factory_consultation.txt

Nyashプログラミング言語の統合Box管理システムについて深い相談です。

【Nyashの哲学と特徴】
- Everything is Box: すべてがBoxオブジェクト
- birthでインスタンスを生み、finiで解放する統一ライフサイクル
- メモリ安全性重視（Rust実装、Arc<Mutex>パターン）
- 初学者フレンドリー、明示性重視

【現在の問題点】
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 BuiltinBoxFactory {
    creators: HashMap<String, Box<dyn Fn(&[Box<dyn NyashBox>]) -> Result<Box<dyn NyashBox>, RuntimeError>>>
}

struct UserDefinedBoxFactory {
    interpreter: Arc<NyashInterpreter>
}

struct PluginBoxFactory {
    registry: Arc<BoxFactoryRegistry>
}

// 統合レジストリ
struct UnifiedBoxRegistry {
    factories: Vec<Box<dyn BoxFactory>>,
}

impl UnifiedBoxRegistry {
    pub fn create_box(&self, name: &str, args: &[Box<dyn NyashBox>]) -> Result<Box<dyn NyashBox>, RuntimeError> {
        // 優先順位: ビルトイン → ユーザー定義 → プラグイン
        for factory in &self.factories {
            if factory.box_types().contains(&name) && factory.is_available() {
                return factory.create_box(name, args);
            }
        }
        Err(RuntimeError::InvalidOperation {
            message: format!("Unknown Box type: {}", name)
        })
    }
}
```

【期待される効果】

1. コード削減
   - 600行のmatch文 → 30行程度のHashMap登録
   - 重複コード削除

2. 保守性向上
   - 新しいBox追加が簡単（HashMapに登録するだけ）
   - birth/finiライフサイクルの統一管理
   - エラーハンドリングの一元化

3. 拡張性
   - RemoteBoxFactory、AsyncBoxFactory等も同じインターフェースで追加可能
   - WASM向けの条件付きコンパイルが簡単

4. パフォーマンス
   - HashMapルックアップは高速
   - 動的ディスパッチのオーバーヘッドは最小限

【深い検討事項】

1. 複雑性の評価
   - 現在: 3つの完全に異なるコードパス（複雑）
   - 提案: 1つの統一インターフェース（シンプル？）
   - トレードオフは？

2. birth/finiの統一性
   - すべてのBoxがbirth/finiライフサイクルに従う
   - Factoryパターンでこれをどう保証する？

3. 型安全性
   - Rustの型システムとの整合性
   - 動的ディスパッチの影響

4. 段階的移行
   - 既存コードとの互換性維持
   - どの順序で移行すべき？

5. 実装の簡単さ vs 抽象化
   - 過度な抽象化になっていないか？
   - 初心者にも理解しやすいか？

【質問】

1. この統合により、本当にコードがシンプルになりますか？それとも抽象化により複雑になりますか？

2. 600行のmatch文を30行のHashMap登録に変換することは、保守性の観点から正しい選択ですか？

3. birth/finiライフサイクルの統一性を保ちながら、Factoryパターンを適用する最良の方法は？

4. パフォーマンスへの実質的な影響はどの程度でしょうか？

5. Nyashの「Everything is Box」哲学と「明示性重視」の観点から、この設計は適切ですか？

6. より簡単で、かつ効果的な代替案はありますか？

プログラミング言語設計と実装の専門的視点から、深く考えてアドバイスをお願いします。特に「シンプルさ」と「保守性」のバランスについて重点的に分析してください。