Magnolia Tech

いつもコードのことばかり考えている人のために。

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

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

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

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

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

Syntax Summary | Scala 2.13

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

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

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

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


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

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

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

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

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

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

'仕様と、実装、その間にあるもの'…コードを書く人はその距離をコントロールしていかないといけないし、その距離が有るという事実を理解しないといけないのです。

そしてコードを書かない人が発するいつものセリフ...「こんな簡単な仕様を実装するのになんでそんなにかかるの?」という疑問に答えていかないといけないのです。


あ、仕様を満たしていない実装はとにかくダメですね、それはダメです。

ダメなんだけど、いつの間にか「バグも仕様」になってしまう時もあるので、話がさらにややこしくなるけどね!