### 原文の場所

- pattern_matching.rd
  - cf. https://github.com/ruby/ruby/blob/v3_2_0/doc/syntax/pattern_matching.rdoc
- control.rd
  - cf. ruby/ruby@281b350

### pattern_matching.rd の配置に関して

## pattern_matching.rd の配置に関して

rurema/doctree の `refm/doc/spec` 配下と ruby/ruby の `doc/syntax` 配下が似たようなファイル構成になっているため、 pattern_matching.rd も `refm/doc/spec` に配置した
また今後可能なら doc 配下のファイルやクラス・モジュール・ライブラリのヘッドラインに rdoc へのリンクを追加したいと思っているが、その場合にディレクトリ・ファイル構成を ruby/ruby に寄せておくほうが実装しやすいのではという思惑もある

#@SampleCode から #@EnD までは COPY が実行できる最小範囲を基準にした

素の rdoc と bitclust の文法の違いを反映するため

- サンプルコード・整形済みテキストの行頭の余分なインデントを削除
- 箇条書きのスタイルを適用するためインデントを追加

- 翻訳する際、原文は対応箇所を把握しやすくするため bitclust のコメント機能を使って残している
- unpack は Python に「アンパック」という用語があるのでとりあえずそのまま「アンパック」と訳している
  - cf. https://docs.python.org/ja/3/tutorial/datastructures.html#tuples-and-sequences

- 翻訳する際、原文は対応箇所を把握しやすくするため bitclust のコメント機能を使って残している
- パターンの名称にアルファベットが含まれる場合は頭文字大文字で統一している
- respond to に関しては「実装もオブジェクト自体が持つ」のと「応答できる」だと意味が異なり、どのように翻訳するか迷ったが注記を追加し Object#respond_to? へのリンクを追加することで respond to の意味での『〜を持つ』だということを説明した
- rest に関しては rest parameter の日本語名に合わせて「残余」と訳した
  - cf. https://secret-garden.hatenablog.com/entry/2022/03/11/210246
  - ただ「残余」とだけ書かれていても分かりづらいため、カッコつきで rest も併記してみた

- 翻訳する際、原文は対応箇所を把握しやすくするため bitclust のコメント機能を使って残している
- パターンの名称にアルファベットが含まれる場合は頭文字大文字で統一している
- rest に関しては rest parameter の日本語名に合わせて「残余」と訳した
  - cf. https://secret-garden.hatenablog.com/entry/2022/03/11/210246
  - ただ「残余」とだけ書かれていても分かりづらいため、カッコつきで rest も併記してみた

- 翻訳する際、原文は対応箇所を把握しやすくするため bitclust のコメント機能を使って残している

…のマッチング) を翻訳

- 翻訳する際、原文は対応箇所を把握しやすくするため bitclust のコメント機能を使って残している
- パターンの名称にアルファベットが含まれる場合は頭文字大文字で統一している

- 翻訳する際、原文は対応箇所を把握しやすくするため bitclust のコメント機能を使って残している

- 翻訳する際、原文は対応箇所を把握しやすくするため bitclust のコメント機能を使って残している
- Ruby 3.2 ではおそらくこの節は不要だがまだ ruby/ruby 側でマージされていないため分岐は入れていない
  - cf. ruby/ruby#7052

- 翻訳する際、原文は対応箇所を把握しやすくするため bitclust のコメント機能を使って残している

- 翻訳する際、原文は対応箇所を把握しやすくするため bitclust のコメント機能を使って残している

素の rdoc と bitclust の文法の違いを反映するため

素の rdoc と bitclust の文法の違いを反映するため

素の rdoc と bitclust の文法の違いを反映するため

- 見出しレベル2だと見た目の主張が強すぎるため
- 他のドキュメントでも見出しレベル2を飛ばして見出しレベル3を利用するケースが多そうだった
  - cf. https://github.com/rurema/doctree/blob/a770b9a74b1e8d1e0918e97fc390f9ae00cfec19/refm/doc/spec/control.rd
  - https://github.com/rurema/doctree/blob/a770b9a74b1e8d1e0918e97fc390f9ae00cfec19/refm/doc/spec/def.rd

…rorが発生する)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (review)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (review)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (review)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (review)

cf. rurema#2773 (comment)

> 原文中で『sub-pattern』としているところは、具体的にArrayパターン、Findパターン、Hashパターンの構文で指定されている`<subpattern>`の場所そのものを指していると思われるが、これをどう翻訳するか。カタカナ「サブパターン」は避けたいと感じる
> * 具体的には、プルリクファイル「refm/doc/spec/pattern_matching.rd」の312, 393, 506行目らへんなど
> * カタカナで『サブパターン』とすると、原文と違い、字面が別物なので「パターン**構文**のあの場所に相当するところかぁ」という気持ちにならない。説明なく現れて消える用語になってしまい、混乱するので、使用を避けたい
> * 文脈的に、「構文部分の`<subpattern>`のことだね、ウンウン」を意識する必要性自体は薄そう（「まあ、マッチに使うパターンの部分のことやろ」と察せられる）
> * 変更案（例）
>
>   * いっそ、全部バッサリ「パターン（部分）」などにしてしまう
>   * 丁寧に...312, 393行目は本文中で余裕もあるので、「サブパターン（Array/Find/Hashパターン構文の`<subpattern>`の部分）」とし、506行目はコードコメントなので「パターン」にする

cf. rurema#2773 (comment)

> respond to `foobar`のような部分は、「foobar **メソッド**を持つオブジェクト」「オブジェクトに foobar メソッドを定義する」と直接的に表現するのはどうだろうか（そして注釈を削除し、respond toの香りを無くす）
> * respond toをあまり大事にする必要がないと思うため：
>
>   * トレイトやインターフェイスのないRubyでは、ダックタイピング的に実装することになるが、そこまでくると、直接的に「メソッドを持つ」でいいと感じる
>   * ココをうまく使いこなすのに、内部の挙動である`Object#respond_to?`まで踏み込んで理解する必要性は薄く（個人的見解）、却って（初心者寄りの読者は特に）混乱を招きそう

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (review)

- 短さのために、常体（not 丁寧語）に
- 能動態を中心に使う
- ～が出力されます -> ～と出力

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (review)

ディスカッション中のものを除く

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (comment)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (comment)

> 『**nil』 を指定する方法以外はないので
>
> 元々の翻訳いただいた文章を活かす場合、
>
> > また、パターンで明示的に指定されたキー以外にキーが存在しないケースにマッチングさせたい場合**のために**、『**nil』 を指定する方法もあります。」
>
> のようにできると思いますが、ここは原文の文体を維持するよりも、「こういうときは、こうする」という書き方に寄せています。

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

rurema#2773 (comment)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (comment)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (comment)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (comment)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (comment)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (comment)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (comment)

> 「変数の束縛の機能」の話ではなく、「変数の束縛の機能の存在のせいで、制限が生まれる」という話だと思われます。
>
> そもそも原文（Due to the variable binding feature, ...）に対して、あんまり親切とは言えない・無くなっても困らないレベルの中途半端な言及の仕方だなぁと感じているので、変更案では、ちょっと手厚めにしています。

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (comment)
cf. rurema#2773 (comment)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (review)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (comment)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (comment)

Co-authored-by: shuichi <shuichi.shp.code@gmail.com>

cf. rurema#2773 (comment)

> 4. 用語『束縛』に対しては、「（Rubyでは）代入と読み替えていいよ」という注釈をつけるか、いっそ『代入』に書き換えるか、をした方が親切に思う
>   - 個人的には、パターンマッチの文脈で他の言語に触れた際の『束縛』に橋渡しできるので、注釈を一発入れて『束縛』という用語は残していいかも

cf. rurema#2773 (comment)

> ## 4. 用語『束縛』について
> > > 「（Rubyでは）代入と読み替えていいよ」
> >
> >
> > とあるんですがこれは
> > > 「（Rubyでは 値の束縛といいつつ再代入ができるので ）代入と読み替えていいよ」
> >
> >
> > という解釈で合っていますか？ 👀
>
> そう...なのですが、私の大元の意図の記載について言及し忘れておりまして、このパターンマッチのドキュメントは、「特に他のプログラミング言語の知識がないRubyユーザが読んでも理解できるドキュメント」であるべきかなぁと考えておりました。
>
> となったときに、「関数型言語のimmutableな変数（らしきもの）に代入（らしきことをする）動作」と詳しく対応させる＆そのためにそれらの言語を知る必要性を、前提に置くことなしに、読めてほしいなと思います。
>
> また、Rubyに置き換える際には、言語の仕組みが違うので、正確に1対1の用語の射影はできない＝いわゆる妥協をする必要があると思っています。
>
> ...ということを込めて、
>
> > 「『束縛』は、パターンマッチの輸入元である関数型言語なんかの用語で、ここでも使っているんだけども、（Rubyでは）代入と読み替えていいよ」
>
> というのは、
>
> > 「『束縛』は、パターンマッチの輸入元である関数型言語なんかの用語で、ここでも使っているんだけども、**（ここで『束縛』って初耳です、なぁにそれ、という方々、細かいことは考えなくていい！）**『束縛』は（Rubyでは）代入と読み替えていいよ **（勿論、ホントは関数型言語における『束縛』との比較などの細かい話はあるけれども、だ）** 」
>
> みたいな意味合いでした...😅
>
> （私の場合、Lispや不慣れなHaskellの知識ぐらいしかないので、ここで言っていることが頓珍漢な可能性があります；Lispは『関数型言語』の文脈で出すべきかはアレですが）

cf. rurema#2773 (comment)

以下のコミットの内容を分岐に取り込んだ

cf. [DOC Update pattern matching docs for 3.2](ruby/ruby@ce0f3de)
cf. [Allow omission of parentheses in one line pattern matching](ruby/ruby@ecb6d6a)
cf. [
Add pattern matching pin support for instance/class/global variables](ruby/ruby@fa87f72)
cf. [Pattern matching pin operator against expression](ruby/ruby@2186347)
cf. [
Update documentation for pattern matching](ruby/ruby@4902f96)
cf. [Reintroduce expr in pat](ruby/ruby@88f3ce1)
cf. [Pattern matching is no longer experimental](ruby/ruby@b601532)

rurema#2773 (comment) の方針で修正