breakとは「loopのGOTO」のことで、回避しなければならないものです。
breakは、GOTOが持つのと同じ正確な方法で、ごみ箱に置かなければなりません。
証拠としてlabelがあります。
他言語では、labelはGOTOに対応するものです。
JavaScript内では、labelはbreakとcontinueに対応しています。
breakとcontinueは同じlabel群から生じているので、GOTOにきわめて近い関係のものをつくります。
JavaScriptのlabelや、break、continueは、GOTOと構造化されていないプログラミングの日々からの残された遺産です。
- （イラスト内の訳）
- プログラムの流れを再構築できた、あるいは代わりに1つの小さな「GOTO」を使った。
- 何だって？優れた実践をねじ込む？どれぐらい悪いのかな？
“「ですが、それは誰にも悪影響を及ぼしていないので、私たち自身が選択できるように言語内でそれを取り除いたらどうですか？」
なぜソフトウェアの書き方に制限を定めるべきなのか？
直観に反するようですが、制限を設けるのは良いことです。
GOTOの除去はこの完璧な例です。
制限はソフトウェアを書く上で、良い影響をもたらします。
breakに代わるものは何か？
全てに素早く簡単にフィットする代用品はありません。
それがプログラムに対する他とは異なる、機能的な考え方です。
私たちは「cats」や「Kitten」と呼ばれる機能の単純なコレクションから始めます。
これらは、後に続くあらゆる例の中で使用されます。
loopの例から始めましょう。最初のkittenを見つける時にcatsとbreakを通じてloopが行われます。
さぁ、lodashに相当するものと比較してみましょう。
その例はかなり単純です。さぁ、もう少し特別なケースを見ていきましょう。
5つの「kitten」を見つけてから、「cat」と「break」を列挙しましょう。
簡単な方法
「lodash」は本当に素晴らしいものですが、専門的な知識を必要とします。
ここで、「lazy.js」の登場です。「Lazy」こそが私たちの欲しているものです。
難しい方法
最初のステップはKittyのloopを機能の中に入れることです。
次に、機能を一般化してcat特有のものを全て抜き出しましょう。「5」を「limit」と入れ替え、「Kitten」を「predicate」、「cats」を「list」をそれぞれ入れ替えてください。
それから、機能へのパラメータとして、それらを加えてください。
現在、実用的で再利用できる「take First機能」があります。
その機能はcatビジネスの論理からは完全に切り離されています。
私たちの機能は純粋なもので、同じ入力が行われれば100%同じものが出力されます。
そこにはまだloopを扱いにくくするものがあるので、リファクタリングを保ちましょう。
次のステップである「newList」「argument list」に移ります。
制限が0に達するときや再帰的プロセス中に秒読みが行われる時、あるいはlistの終わりに達する時に、私たちは再帰をbreakしたくなります。
breakを行わないのであれば、その後にfilter述語がマッチするかをチェックします。
マッチしていればtakeFirstを呼び込みます。制限を減らしnewListに追加するか、list内の次のアイテム上に移動させてください。
また、三項演算子と入れ替える最終ステップについて説明します。
現在、私たちは次のような新しい方法を利用できます：
追加として、私たちはtakeFirstを使用してその他の機能をつくることができました。
要約
私たちには、「lodash」や「ramda」、「lazy.js」のような便利で素晴らしいライブラリーがたくさんあります。
再帰を使用すればオリジナルの手法をつくることさえ可能です。
takeFirstがきわめて優れている一方で、警告しなければならないこともあります。
JavaScript-land内における再帰は非常に危険であり、スタックサイズがエラーメッセージを上回ったという悪名高い「Maximum call」を得ることは簡単なのです。
※本稿は「Rethinking JavaScript: Replace break by going functional」を翻訳・再編集したものです。
おすすめ新着記事
おすすめタグ