# フィールド宣言位置の制約設計（2025-09-15）

## 概要

Boxのフィールド宣言がメソッドの間に散在できる問題に対する設計相談。AIとの対話を通じて、複雑なinitブロック案から「フィールドは先頭のみ」という単純明快なルールへ収束した事例。

## 相談の流れ

### 1. 問題提起（ユーザー）
```
ところで　今のフィールド変数の書き方
これだと　どこでもかけちゃうのかな
```

現状の問題：
```nyash
box MessyBox {
    field1: StringBox
    method1() { }
    field2: IntegerBox  // メソッドの間に散在
    birth() { }
    field3: BoolBox     // さらに散在
}
```

### 2. 初期提案（ユーザー）
```
init
{
    この中に書く　書き方は今のと同じ
}
init文復活させて　この中だけにフィールドを書くというのはありかもしれない
```

### 3. AI分析（Claude）

#### initブロック案の評価
**メリット**:
- 明確な構造化
- フィールド一覧の固定位置
- パース簡略化
- 将来の拡張性（アノテーション等）

**デメリット**:
- 冗長性（小さなBoxでも必須）
- Everything is Box哲学との齟齬
- 学習コスト増加

#### ハイブリッド提案
```nyash
// 小さなBoxはそのまま
box SmallBox {
    name: StringBox
    birth(n) { me.name = n }
}

// 大きなBoxはinitで整理
box LargeBox {
    init {
        field1: TypeBox
        field2: TypeBox
    }
    birth() { }
}
```

### 4. ユーザーの洞察
```
それか　フィールドは　boxの先頭だけにかけるというルールはありかもしれにゃい
```

### 5. 収束（AI）

「フィールドは先頭のみ」ルールの支持：

```nyash
box CleanBox {
    // フィールドは必ず先頭にまとめる
    field1: StringBox
    field2: IntegerBox
    
    // ここから下はメソッドのみ
    birth() { }
    method1() { }
}
```

**決定的な利点**:
- 特別な構文不要（initブロック不要）
- 多くの言語で採用されている標準
- パーサー実装が簡潔
- Everything is Box哲学と調和

## 設計哲学の体現

1. **単純性の追求**: 複雑な構文（initブロック）より単純なルール
2. **制約による明快さ**: 自由度を制限して可読性を向上
3. **段階的移行**: 警告→エラーの段階的導入
4. **既存の知見活用**: 他言語の標準的アプローチを採用

## AI協働パターン：段階的洗練型

1. **複雑な提案から開始**（initブロック、ハイブリッド案）
2. **詳細な分析提供**（メリット・デメリット・他言語比較）
3. **ユーザーの直感的提案**（先頭のみルール）
4. **AIが即座に価値を認識**
5. **実装戦略まで具体化**

→ AIは複雑に考えがちだが、人間の直感が本質を突く好例

## 教訓

- 最良の設計は説明不要な設計
- 制約は自由度を奪うのではなく、明快さを与える
- "Everything is Box"は複雑さの言い訳ではない
- AIの分析力と人間の直感の相補性

## 実装計画

1. **Phase 15.4**: 警告モード（`NYASH_STRICT_FIELD_ORDER=warn`）
2. **Phase 16**: エラーモード（`NYASH_STRICT_FIELD_ORDER=error`）
3. **Phase 17**: デフォルト化

## 関連

- 論文D（AI協働パターン）: 段階的洗練型の実例
- 論文I（開発秘話）: 言語設計の転換点として記録