問題タブ [partialfunction]

がある限り、PartialFunction[X,R]それを返す関数に変換するのは非常に簡単ですOption[R]。

ただし、タスクが逆の場合はどうなるでしょうか。引数としてf取得し、結果として返す関数があるとします。そして、私はそれを作りたいと思っています。最善の方法は何ですか？XOption[R]PartialFunction[X,R]

私が思いついたものは、私の好みにはかなり醜く見えます：

私が逃したより良い方法はありますか？

String から部分関数へのマップを作成しているときに、予期しない動作に遭遇しました。部分関数をマップ要素として作成すると、正常に機能します。val に割り当てると、代わりに呼び出されます。チェックを呼び出そうとすると、エラーが発生します。これは期待されていますか？私は愚かなことをしていますか？をコメントアウトしてcheck()、呼び出しを確認します。私はscala 2.7.7を使用しています

部分関数を継承するいくつかのクラスを設計しようとしていますが、構文を完全に正しく理解できないようです。私のスーパークラスは次のようになります。

そして、サブクラスは次のようになります。

しかし、これはこのエラーでコンパイルに失敗します

私はこれについてたくさんのバリエーションを試しました、誰かが正しい構文が何であるか知っていますか？

リフト開発ではmatch、次のような –<code>case ステートメントを使用する必要がある場合があります。(理解しやすいように単純な scala に書き直しました。) 彼らへの 1 つの注意: これらは実際には異なる部分関数であり、コードの異なる部分で定義されているため、case ステートメントがガード内またはガードの前で失敗することが重要です関数が評価されます (マッチングが失敗した場合、つまり)。

ここで、caseステートメントが成功したことを確認するために、データベースにクエリを実行しfindInDb、結果が有効かどうかを確認する必要があります。その後、値を使用するためにもう一度呼び出す必要があります。

のようなことをする

resの範囲が中括弧内に限定されるため、 は機能しません。

もちろん、外部を定義しvar res = _て割り当てることはできますが、これを行うのは気分が悪いです。

ガード内で変数を宣言することはどうしても可能ですか? それが可能ならcase r@Req(…)、なぜcase r@Req() if res@(r.isDefined)ですか？

私は時々次のパターンに出くわします、そこで私は本質的にを持っていてPartialFunction[SomeType,AnotherType]、それをとして扱いたいですFunction[SomeType,Option[AnotherType]、例えば：

デフォルトのケースを回避し、結果を定義された場所にラップする方法で上記の関数を作成する方法はありますSomeか？私がこれまでに思いついた最高のものはこれです：

中間関数を定義せずにそれを行う方法はありますか？私はすでに次のようにさまざまなことを試しましたが、まだコンパイルするものがありません。

与えられた:

私はそれを呼び出すことができます：

部分適用による興味深い動作は次のとおりです。

コードブロックは、関数として渡されることなく、すぐに評価されます。上記の2つのステートメントの違いは何ですか?

私は何かが欠けていると思います：

このエラーが発生するのはなぜですか？私はどのように機能するか誤解していると思いますcollect...

ステートメントを使用してPartialFunction例外を作成する方法はありますか?case

気になるのは、次のように表現したいからです（scala疑似アヘッド！）...

...部分関数として、および実行

二度作成するので冗長に思えますBigInt。

次の点を考慮してください。

私はこれを行うことができると思いました：

しかし、いいえ。ここで基本的なものが欠けていますか？私の希望は、私の PartialFunction を match ステートメントで使用および再利用できることでした。これは不可能ですか？

部分関数

Scala では、aPartialFunctionは要するに、isDefinedAtメソッドを追加で定義する関数です。

一連のcaseステートメントで部分関数を定義するのは簡単です。些細な例は、たとえば次のようになります。

isDefinedAtcase部分関数を定義する のリストから自動的に生成されます。

環境

Lift フレームワークは、リクエストを Lift のエンジンで処理するか、ディスク上のファイルからそのまま処理するかを定義するなど、多くの場所で部分関数を使用します。また、caseすべての入力パラメーターに一致するステートメントを作成し、値を返すかどうかを後で決定したいと思うこともあります。これは、最初の一連のcases では、関数が特定の値で定義されているかどうかを判断するのに十分ではないことを意味します

たとえば、Lift では、すべての html および htm ファイルが直接提供され、拡張子が「lift」のファイルを処理する必要があるというルールを追加したいと考えています。次のようなことをするのは簡単に見えます:

残念ながら、この場合、コンパイラは、最初の関数がcase常に一致するため、部分関数がどこでも定義されていると見なします。matchすべての受信リクエストに一致しない可能性があるのは、ネストされたものです。そして、リクエストが一致しない場合は、 aMatchErrorがスローされます。

質問

match部分関数を定義するときにコンパイラにネストされたステートメントを考慮させる簡単な方法はありますか、またはこのようにネストされたすべての条件をインライン化する唯一の方法はありますか?

この例では、ほとんど実行可能ですが、可読性が低下し、すべてのチェックをインライン化すると非常に見苦しく見えるケースに直面しました。