a5ff3ecafe
- Implement BID Box Bridge interface for Nyash Box <-> BID Handle conversion - Add StringBox BID bridge implementation with handle/TLV support - Add IntegerBox BID bridge implementation with handle/TLV support - Implement BoxRegistry for managing Box instances and handles - Add comprehensive tests for StringBox/IntegerBox BID round-trip - Extract helper functions for string/integer value extraction Everything is Box philosophy shines through unified BID integration! 🎉 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
125 lines
4.7 KiB
Plaintext
125 lines
4.7 KiB
Plaintext
Nyash「箱理論」に基づくBID-FFI設計の最終レビューをお願いします。
|
||
|
||
【Nyashの箱理論（Everything is Box）】
|
||
Nyashプログラミング言語は「Everything is Box」哲学を採用しており、すべてのデータと機能がBoxとして統一されています。
|
||
|
||
既存のBox型:
|
||
- StringBox, IntegerBox, BoolBox（基本型）
|
||
- ArrayBox, MapBox（コレクション）
|
||
- FutureBox（非同期処理）
|
||
- P2PBox（ネットワーク）
|
||
- FileBox（将来プラグインで提供予定）
|
||
|
||
【設計の変遷】
|
||
1. 最初の設計: 野心的すぎて複雑（gRPC/REST/P2P等全部）
|
||
2. ChatGPT提案: 一般的で正しいが、既存FutureBoxと二重実装になる
|
||
3. 最終設計: 箱理論準拠の最低設計
|
||
|
||
【最終設計案】
|
||
|
||
```rust
|
||
// 1. 型システム：プリミティブ + Handle統一
|
||
pub enum BidType {
|
||
// プリミティブ（FFI境界で直接渡せる）
|
||
Bool, I32, I64, F32, F64, String, Bytes,
|
||
|
||
// Everything is Box: すべてのBoxは統一Handle
|
||
Handle(String), // "StringBox:123", "FileBox:456", "FutureBox:789"
|
||
|
||
// メタ型
|
||
Void,
|
||
|
||
// Phase 2以降（定義だけ）
|
||
Option(Box<BidType>),
|
||
Result(Box<BidType>, Box<BidType>),
|
||
Array(Box<BidType>),
|
||
}
|
||
|
||
// 2. 既存Boxとの対応
|
||
/*
|
||
Handle("StringBox:123") → 既存StringBox インスタンス
|
||
Handle("FileBox:456") → プラグインFileBox
|
||
Handle("FutureBox:789") → 既存FutureBox（非同期）
|
||
Handle("P2PBox:101") → 既存P2PBox
|
||
*/
|
||
|
||
// 3. 統一エントリーポイント
|
||
extern "C" fn nyash_plugin_invoke(
|
||
box_type_id: u32, // StringBox=1, FileBox=6等
|
||
method_id: u32, // open=1, read=2等
|
||
instance_id: u32, // Handle解析用
|
||
args_ptr: *const u8,
|
||
args_len: usize,
|
||
result_ptr: *mut u8,
|
||
result_len: *mut usize,
|
||
) -> i32
|
||
|
||
// 4. Boxヘッダー統一
|
||
#[repr(C, align(8))]
|
||
pub struct BoxHeader {
|
||
magic: u32, // "NYBX"
|
||
version: u16,
|
||
type_id: u32, // BoxTypeId
|
||
instance_id: u32, // インスタンス識別子
|
||
ref_count: u32, // 非atomic（シングルスレッド中心）
|
||
flags: u32, // 拡張用
|
||
}
|
||
|
||
// 5. 既存Box統合
|
||
pub struct NyashBoxRegistry {
|
||
instances: HashMap<u32, Arc<RwLock<dyn NyashBox>>>,
|
||
}
|
||
|
||
impl NyashBoxRegistry {
|
||
fn call_method(&self, type_id: u32, instance_id: u32, method_id: u32, args: &[u8])
|
||
-> Result<Vec<u8>, BidError> {
|
||
match type_id {
|
||
1 => self.call_stringbox_method(...), // 既存StringBox
|
||
6 => self.call_filebox_method(...), // プラグインFileBox
|
||
7 => self.call_futurebox_method(...), // 既存FutureBox活用
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
【設計原則】
|
||
1. **箱理論準拠**: すべてのBoxが同じ仕組みで扱える
|
||
2. **既存資産活用**: FutureBox等の既存実装を最大活用
|
||
3. **最低設計**: 動くものを最速で、複雑な機能は後回し
|
||
4. **二重実装回避**: 新しいBidFutureではなく既存FutureBox使用
|
||
5. **シングルスレッド中心**: Nyashの現実に合わせた設計
|
||
|
||
【具体的な利点】
|
||
- Nyashコード側は変更不要（local file = new FileBox("test.txt")）
|
||
- 既存StringBox, ArrayBox, FutureBoxと新しいプラグインFileBoxが同じ仕組み
|
||
- Handle("BoxType:id")による統一的なBox参照
|
||
- 非同期はFutureBoxで、新実装不要
|
||
|
||
【質問】
|
||
|
||
1. **箱理論の技術的妥当性**
|
||
- すべてをHandle統一する設計は適切か？
|
||
- 既存BoxとプラグインBoxの統一的な扱いは可能か？
|
||
- FFI境界でのBox参照としてHandle("Type:id")は適切か？
|
||
|
||
2. **最低設計のメリット・デメリット**
|
||
- プリミティブ + Handle のみの設計は十分か？
|
||
- 複雑な型（Array, Map等）を後回しにする判断は？
|
||
- Phase 1で基本動作、Phase 2で拡張の戦略は妥当か？
|
||
|
||
3. **既存資産活用の是非**
|
||
- 新しいBidFutureを作らずFutureBox活用は正解か？
|
||
- 既存のStringBox等との統合アプローチは適切か？
|
||
- 二重実装回避 vs 設計の純粋性のトレードオフは？
|
||
|
||
4. **実装現実性**
|
||
- 1週間でのPhase 1実装は現実的か？
|
||
- 既存インタープリターとの統合難易度は？
|
||
- Linux x86-64限定での最初の実装は妥当か？
|
||
|
||
5. **将来拡張性**
|
||
- この基盤で将来のgRPC/REST対応は可能か？
|
||
- Transport抽象化への拡張パスは明確か？
|
||
- P2P（NyaMesh）統合への道筋は適切か？
|
||
|
||
「箱理論」という独特な哲学を持つNyashにとって、一般的なFFI設計とは異なる特殊なアプローチが必要だと考えています。この「最低設計から始めて段階的拡張」の戦略についての専門的見解をお願いします。 |