45 lines
1.8 KiB
Plaintext
45 lines
1.8 KiB
Plaintext
|
Nyashプログラミング言語の設計判断について追加相談です。
|
|||
|
|
|
|||
|
|
【前回の結論】
|
|||
|
|
透明化システム廃止・明示的システム採用が最良との分析をいただきました。
|
|||
|
|
|
|||
|
|
【新しい提案】
|
|||
|
|
ユーザー側は「birth()統一」にして、内部実装の複雑さは隠蔽する案です：
|
|||
|
|
|
|||
|
|
```nyash
|
|||
|
|
# ユーザー側: 全てbirth()で統一
|
|||
|
|
box EnhancedString from StringBox {
|
|||
|
|
birth(content, prefixStr) {
|
|||
|
|
from StringBox.birth(content) # ← 明示的だがシンプル
|
|||
|
|
me.prefix = prefixStr
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
【内部実装の柔軟性】
|
|||
|
|
```rust
|
|||
|
|
// StringBox内部でのbirth()実装
|
|||
|
|
impl StringBox {
|
|||
|
|
pub fn birth(content: String) -> Self {
|
|||
|
|
// 内部的にはpackでもnewでも何でも使える
|
|||
|
|
Self::new(content) // または Self::pack(content)
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
【この案の特徴】
|
|||
|
|
1. **明示性**: from StringBox.birth() で何をしているか明確
|
|||
|
|
2. **シンプル**: ユーザーはbirth()だけ覚えればいい
|
|||
|
|
3. **実装自由度**: ビルトインBoxの内部実装は自由
|
|||
|
|
4. **一貫性**: ユーザー定義・ビルトイン両方で同じAPI
|
|||
|
|
5. **適切な抽象化**: 実装詳細の隠蔽であり、動作の隠蔽ではない
|
|||
|
|
|
|||
|
|
【検証したい点】
|
|||
|
|
1. 前回のbirth/pack区別案 vs birth統一案、どちらが優れているか？
|
|||
|
|
2. 「内部実装隠蔽」はNyash明示性哲学と矛盾しないか？
|
|||
|
|
3. ユーザーの学習コスト・認知負荷の観点では？
|
|||
|
|
4. APIの将来拡張性（from_json等）への影響は？
|
|||
|
|
5. 実装・保守の観点での優劣は？
|
|||
|
|
6. 「適切な抽象化レベル」として妥当か？
|
|||
|
|
|
|||
|
|
前回の深い分析を踏まえ、この「birth()統一・内部実装自由」案の妥当性を言語設計の専門的視点から分析してください。
|