55 lines
2.1 KiB
Plaintext
55 lines
2.1 KiB
Plaintext
|
Nyashプログラミング言語の根本的設計哲学について深い相談です。
|
|||
|
|
|
|||
|
|
【Everything is Box哲学と実用性の矛盾】
|
|||
|
|
- Nyashは「Everything is Box」を掲げ、全ての値がBoxオブジェクト
|
|||
|
|
- しかしStringBox等の基本Box型で継承チェーン問題が発生
|
|||
|
|
- 基本的な機能を使うのに過度な複雑性が要求される
|
|||
|
|
|
|||
|
|
【現在の問題例】
|
|||
|
|
box Simple from StringBox {
|
|||
|
|
toString() {
|
|||
|
|
return "Prefix: " + from StringBox.toString()
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
box Complex from Simple {
|
|||
|
|
toString() {
|
|||
|
|
# ❌ エラー: ComplexはStringBoxに直接fromしていない
|
|||
|
|
return "Complex: " + from Simple.toString() # Simple内でStringBoxが呼ばれる
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
【static提供案】
|
|||
|
|
StringBoxのような基本Box型をstatic methodsとして提供：
|
|||
|
|
|
|||
|
|
box Simple {
|
|||
|
|
init { content }
|
|||
|
|
toString() {
|
|||
|
|
return "Simple: " + StringBox.toString(me.content) # static呼び出し
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
box Complex from Simple {
|
|||
|
|
toString() {
|
|||
|
|
return "Complex: " + from Simple.toString() # 問題なし
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
【哲学的ジレンマ】
|
|||
|
|
1. **Everything is Box一貫性**: 全てがBoxであるべき vs 基本型の特別扱い
|
|||
|
|
2. **実用性 vs 純粋性**: 使いやすさ vs 設計哲学の一貫性
|
|||
|
|
3. **二重体系の懸念**: Box型とstatic関数の併存は混乱を招くか
|
|||
|
|
|
|||
|
|
【他言語の例】
|
|||
|
|
- Java: String.valueOf()等のstatic methods + Stringオブジェクト
|
|||
|
|
- Python: str()関数 + strオブジェクト
|
|||
|
|
- Rust: String::new() + インスタンスメソッド
|
|||
|
|
|
|||
|
|
【具体的質問】
|
|||
|
|
1. 基本Box型（StringBox, IntegerBox, MathBox等）をstatic提供すべきか？
|
|||
|
|
2. Everything is Box哲学を維持しながら実用性を確保する方法は？
|
|||
|
|
3. Hybrid approach（Box型 + static methods併存）は設計として健全か？
|
|||
|
|
4. 基本的すぎるBox型の「特別扱い」は言語設計として妥当か？
|
|||
|
|
5. 継承チェーン問題を根本解決する他のアプローチは？
|
|||
|
|
|
|||
|
|
プログラミング言語の設計哲学と実用性のバランスについて、専門的見解をお聞かせください。
|