アカウント名:
パスワード:
こういうのはエラーチェックのために使うことが多いので条件を満さない要素が1つでもあればfalseで空ならtrueが普通と思う。空かどうかはまた別のチェックということで。
私はこれに同意。
ほかには、絞り込み検索の実装にも使いますね。ある要素が全ての絞り込み条件に適合していれば抽出する、って処理を書くときに、「絞り込み条件が空の場合は適合」となっているとシンプル。
その用途だと「(別に行われてるべき)空チェックを正しくされてない」ことを検出できる、例外を投げる動作が一番理にかなってない?
例外投げればいいじゃない?って意見は同意だけど、例外が使えない言語も考慮して考えておくのもアリだと思う。
strcmpみたいにintで返すのもありかと
汎用的なライブラリ関数を作るのならこれだよな。どんな配列が渡されるか不明だから、最初に初期化(null)確認をして、要素数の確認をして、それらに問題が無ければ実際の処理に入る。戻り値はそれぞれの処理結果に応じて値を変える。汎用的な関数でなく、自分のプログラムの中で管理されて使用されるのなら戻り値はtrueになる。配列が空である事が何らかの意味を持つのであれば、関数を呼び出す前に確認して、処理を記述するから。つまり、関数は初期化して要素数が1以上のものを必ず渡す事を前提に作るから、初期化や要素数の確認はせず、そのまま内容確認の処理を記述する。ループさせ、条件を満たさないものがあれば、処理を中断しfalseで戻す。もし配列が空であれば結果的にtrueになる。
現実的にはって言うなら、自分の場合は、StreamAPI的に、配列にfilter()とかmatch()とかfind()とかで訊ねる、そういう感じで書くだからまず「配列を渡してtrueかfalseを返させる」って状況設定が変だし、trueが返ってくるのも気持ち悪い
「エラーチェックのため」ならそう仕様に書けばいいっていうかそう書くべきで、一律にtrueを返すべきとかの暗黙の了解に委ねるのはちょっと怖いね良いプログラマなら、そこで仕様を確認するか、他の原則を適用して判断して欲しいと思う
Stream.allMatchメソッド涙目
いや、all/anyはいわゆる終端なので、filterやmatchなどとは違っていて当たり前だ。
all/anyは終端処理で使うものだから、何もおかしくない。
そんなことないだろ。var items = getitems()if (isVisibleItemExists(items)) showItems()なんて使われ方もある
∀(all_of)と、∃(exist, any_of)を混同したらダメだよ。メソッド名から察するに、isVisibleItemExists は、「Visibleなアイテムが一つでも存在する場合、true」で、その場合は空ならfalseが普通。
今回の仕様問題に合わせて「全ての要素が」という仕様の書き方をするなら、「全ての要素が非visibleの場合は、falseを返す」という仕様記述になり、(返すtrue/falseが逆なので「元の仕様問題では空の場合はtrueを返すのが普通」と同じ話として)、空の場合はfalseを返すの普通、となる。
後続の「配列に対する処理を適用開始していいかの前チェック」って受け取ったので、自分もtrue派基本的に処理メソッドは空配列を渡しても「何もしない」が原則だと思っているので、空配列はスルーしても問題にはならない仮に空をエラーとするなら例外投げるし
要件を満たすためには必ず真となる値を入れるべきで、空の配列を使うという時点で絶対に実行されないものと考えるしかなく、そうなるとfalse以外には考えられないです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
現実的には (スコア:3, 参考になる)
こういうのはエラーチェックのために使うことが多いので
条件を満さない要素が1つでもあればfalseで空ならtrueが普通と思う。
空かどうかはまた別のチェックということで。
Re:現実的には (スコア:1)
私はこれに同意。
ほかには、絞り込み検索の実装にも使いますね。
ある要素が全ての絞り込み条件に適合していれば抽出する、って処理を書くときに、「絞り込み条件が空の場合は適合」となっているとシンプル。
Re: (スコア:0)
こういうのはエラーチェックのために使うことが多いので
条件を満さない要素が1つでもあればfalseで空ならtrueが普通と思う。
空かどうかはまた別のチェックということで。
その用途だと「(別に行われてるべき)空チェックを正しくされてない」ことを検出できる、例外を投げる動作が一番理にかなってない?
Re: (スコア:0)
例外投げればいいじゃない?って意見は同意だけど、例外が使えない言語も考慮して考えておくのもアリだと思う。
Re: (スコア:0)
strcmpみたいにintで返すのもありかと
Re: (スコア:0)
汎用的なライブラリ関数を作るのならこれだよな。どんな配列が渡されるか不明だから、最初に初期化(null)確認をして、要素数の確認をして、それらに問題が無ければ実際の処理に入る。戻り値はそれぞれの処理結果に応じて値を変える。
汎用的な関数でなく、自分のプログラムの中で管理されて使用されるのなら戻り値はtrueになる。配列が空である事が何らかの意味を持つのであれば、関数を呼び出す前に確認して、処理を記述するから。つまり、関数は初期化して要素数が1以上のものを必ず渡す事を前提に作るから、初期化や要素数の確認はせず、そのまま内容確認の処理を記述する。ループさせ、条件を満たさないものがあれば、処理を中断しfalseで戻す。もし配列が空であれば結果的にtrueになる。
Re: (スコア:0)
現実的にはって言うなら、自分の場合は、StreamAPI的に、配列にfilter()とかmatch()とかfind()とかで訊ねる、そういう感じで書く
だからまず「配列を渡してtrueかfalseを返させる」って状況設定が変だし、trueが返ってくるのも気持ち悪い
「エラーチェックのため」ならそう仕様に書けばいいっていうかそう書くべきで、一律にtrueを返すべきとかの暗黙の了解に委ねるのはちょっと怖いね
良いプログラマなら、そこで仕様を確認するか、他の原則を適用して判断して欲しいと思う
Re: (スコア:0)
Stream.allMatchメソッド涙目
Re: (スコア:0)
いや、all/anyはいわゆる終端なので、filterやmatchなどとは違っていて当たり前だ。
Re: (スコア:0)
all/anyは終端処理で使うものだから、何もおかしくない。
Re: (スコア:0)
そんなことないだろ。
var items = getitems()
if (isVisibleItemExists(items))
showItems()
なんて使われ方もある
Re:現実的には (スコア:2)
∀(all_of)と、∃(exist, any_of)を混同したらダメだよ。
メソッド名から察するに、isVisibleItemExists は、「Visibleなアイテムが一つでも存在する場合、true」で、
その場合は空ならfalseが普通。
今回の仕様問題に合わせて「全ての要素が」という仕様の書き方をするなら、
「全ての要素が非visibleの場合は、falseを返す」
という仕様記述になり、
(返すtrue/falseが逆なので「元の仕様問題では空の場合はtrueを返すのが普通」と同じ話として)、
空の場合はfalseを返すの普通、となる。
Re: (スコア:0)
後続の「配列に対する処理を適用開始していいかの前チェック」って受け取ったので、自分もtrue派
基本的に処理メソッドは空配列を渡しても「何もしない」が原則だと思っているので、空配列はスルーしても問題にはならない
仮に空をエラーとするなら例外投げるし
Re: (スコア:0)
要件を満たすためには必ず真となる値を入れるべきで、空の配列を使うという時点で絶対に実行されないものと考えるしかなく、そうなるとfalse以外には考えられないです。