仕様と、実装、その間にあるもの

妙に時間をかけてしまって一つのPRを書いた。

Fixed Syntax Summary by magnolia-k · Pull Request #9666 · scala/scala · GitHub

Scalaの文法概要の記載が正確ではない(過去の修正で誤りが混入した)箇所を直すものだ。

他の誤りも無いかと確認する過程で、upper(大文字)の定義と、lower(小文字)の定義を読み取るのに非常に苦労した。

ただ、よく読むと分かるが、結局大文字も小文字もletter(文字)に集約されてしまい、構文上の区別は無い(大文字と小文字が使える箇所に差はない）。

また、実装上もJavaの Character.isUnicodeIdentifierStartや、Character.isUnicodeIdentifierPartを使って判定されているが、結局どちらも大文字と小文字による分岐は存在しない。

つまり、仕様は複雑（大文字と、小文字を細かくパターン分け）な割りに、実装は非常にシンプルになっている。かと言って何か仕様に反した実装がされているわけでもない。仕様を満たすように正しく実装されている。

(UnicodeのOther_Lowercaseというプロパティがどうのこうの...と出てくる割に、実装上はどこにも出てこないので不思議に思っていた)

このように、仕様は複雑だけど、パターンを読み切って実装は実にシンプルにまとまっている事例というのは案外いろんなところに存在する。だからといって、「仕様」を「実装」に合わせて描き直してはいけない。

仕様は仕様であり、実装は実装だからだ。

この仕様が拡張された時、やはりその複雑さに合わせてコードを書き直さないといけない時だってくるかもしれない。仕様はあくまで当初の意図がしっかり残っていなければいけないし、実装はそれを満たさなければいけないけど、完全に一致している必要もまたない。

それが将来に良い結果をもたらすかもしれないし、悪い結果をもたらすかもしれない。

技巧的に走りすぎたコードが良いとは限らないけど、それでも実装の効率性や、将来の拡張性を考えた時に、必ずしも仕様の字面通りのコードがベストであるとも限らない。

一方で確実に読み取りづらくなるのも事実で、そこに何らかの意図をコメント等で残しておかないと後世の人は混乱するだけかもしれない。

仕様と、実装が別の表現だと混乱するけど、仕様を満たすように実装されていれば、それはそれで正しいわけだし、たまたま実装方法として便利な既存のメソッドが有って、仕様を満足するならそれでいいんだけど、既存のメソッドの責務が大きい時に、「本当にこれでいいんだっけ？」と思って時間が溶ける
— magnoliak🍧 (@magnolia_k_) June 13, 2021