俺があんな極端な事例を出したのは、あれが「ソースコードの見た目を変えるだけで意味をまったく変えない事例」のわかりやすい事例だからなんだがな。 typedef は適切に使えばコードの意味をより明確にする事ができるけど、俺が例に出した C 風 Algol のコードは単に C のコードの見た目を Algol 風にしてるだけで、コードの意味をより明確にするという効果はないといって良いだろ。
list へのエイリアスとして List を作るなんてのは、まさにこの見てくれだけの問題で、別に list が List になったからといってコードの意味は変わらないだろ。それはどっちにしてもリストだからだ。だったら俺の出した例に近いものとして挙げられてる「Array = list」の方が良し悪しは別としてソースコードの意味への影響は大きく、少なくとも「リストではなく配列として考える」という意図が見える。こっち方がより typedef によるコードの意味の明確化に近いニュアンスで、「List = list」よりは意味がある。まあ、だったら「class Array(list): pass」とでもして、将来において実装を変えたくなったときに備えた方が良いとは思うけど。
自分好みの見てくれのコードを書きたいという欲求はわからないでもない。ただ、それを実現するためにコードの意味をまったく変えない別名定義を、よりによって素の組み込み型に対してすることはどうなんだと俺は言っている。コードの意味を変えない別名定義が有効なのは、長かったり複雑だったりする型への略称として使い、コードの可読性を上げる(より意図を伝えやすくする)ためのものだろう。特に C 言語は様々な修飾子が存在し、また関数ポインタの絡んだ型が煩雑になりがちなので、そこで typedef を使うのは利に適っていることが多いと思う。では「List = list」が複雑な型名による可読性の低下を軽減してるかというと、とてもそうは思えない。むしろその言語の慣習・標準を無視することで(本人以外の多くの人にとっての)可読性は低下しており、その極北の一つが Bourne Shell のコードなのだ。
『「List = list」としてエイリアスを追加するだけのことを、こんな極端なものと同じように扱われるのはとても心外』とあるが、制御構造に踏み込んでないだけ組み込み型にコードの意図が変わらない無駄なエイリアスを付ける方がまだマシ程度で、手前勝手な見てくれのコードを書くために元の言語のやり方を無視して余計な混乱を招くという意味で、この極端な例とは五十歩百歩、目くそ鼻くそを笑う、どんぐりの背比べだと俺は言っているのだ。
この怪文書はクリエイティブ・コモンズ・ライセンスの元でライセンスされています。引用した文章など Kuwata Chikara に著作権のないものについては、それらの著作権保持者に帰属します。