これは私が今していることです:
private var accounts = Vector.empty[Account]
def removeAccount(account: Account)
{
accounts = accounts.filterNot(_ == account)
}
もっと読みやすい解決策はありますか?理想的には、書きたいと思いますaccounts = accounts.remove(account)
。
これは私が今していることです:
private var accounts = Vector.empty[Account]
def removeAccount(account: Account)
{
accounts = accounts.filterNot(_ == account)
}
もっと読みやすい解決策はありますか?理想的には、書きたいと思いますaccounts = accounts.remove(account)
。
私はこれを使用します:
accounts filterNot account.==
これは私にはかなりよく読めますが、ymmv。count
述語をとらないものも欲しいのですが、コレクションライブラリには、述語を持つものが操作を一般化できる特殊なメソッドが本当に不足しています。
2.8.xまでは、セマンティックの問題のために非推奨になったiircというメソッドがありまし-
た。私の記憶が私に正しく役立っていれば、実際には2.10に戻った可能性がありますが、そうではありませんでした。編集:チェックアウトしたところ、適用されているコレクションを変更する可変-
メソッド用に予約されていることがわかりました。シーケンスでは、最初または最後の要素を何かに等しくするのが理にかなっているので、私はすべて/に賛成です。そのためのチケットを前に出してくれる人はいますか?私はそれを賛成します。:-)-:
:-
あなたはこのようなことをすることができます:
def removeFirst[T](xs: Vector[T], x: T) = {
val i = xs.indexOf(x)
if (i == -1) xs else xs.patch(i, Nil, 1)
}
それから
accounts = removeFirst(accounts, account)
ただし、問題の核心は、物事を引き出したいアイテムのセットVector
に対して、おそらく適切なコレクションタイプではないことだと思います(ヒント:try )。IDまたは挿入インデックスでインデックスを作成する場合は、目的のインデックスにすることができます(メソッドがあります)。複数のものに効率的にインデックスを付けたい場合は、データベースが必要です。Set
Map
-
残念ながらありません。さらに悪いことに (おそらく)、同じアカウントが 2 回存在filterNot
すると、両方が削除されます。読みやすさのために私が提供できる唯一のことは、使用することです
accounts.filter(_ != account)
TreeSet
もう 1 つの可能性は、a (と呼ばれる場所)などの削除操作を持つコレクション型を使用することです-
。とにかく重複するエントリがない場合は、a で問題ありませんSet
。(もちろん、一部の操作では遅くなりますが、アプリケーションにより適している可能性があります。個々のエントリを削除する方が効率的filterNot
です。基本的に全体を再度ビルドする必要がありますVector
。)
diff
すべてのシーケンスに対して定義されているメソッドを使用できます。2 つのシーケンス間のマルチセットの差を計算します。つまり、必要な数の要素の出現を削除します。
Vector(1, 2, 1, 3, 2).diff(Seq(1)) =>
Vector(2, 1, 3, 2)
Vector(1, 2, 1, 3, 2).diff(Seq(1, 1)) =>
Vector(2, 3, 2)
Vector(1, 2, 1, 3, 2).diff(Seq(1, 1, 2))
Vector(3, 2)
クロージャーを使用したくない場合はfilterNot
、代わりに、より冗長で明示的な for-comprehension スタイルを使用できます。
private var accounts = Vector.empty[Account]
def removeAccount(account: Account)
{
accounts = for { a <- accounts
if a != account } yield { a }
}
この場合、これがより良いと感じられるかどうかは、個人的な好みの問題です。
確かに、ネストされた flatMap などを含むより複雑な式については、特に初心者にとっては、for 内包表記の方がかなり読みやすいという Martin Odersky のアドバイスに同意します。