- 1 名前：デフォルトの名無しさん mailto:sage [2016/06/29(水) 23:45:15.36 ID:EZjVZgG6.net]
- ■Visual Studio 2013 Community & Express(無償の統合開発環境)等はこちら
www.visualstudio.com/downloads/
■コードを貼る場合はこちら
ideone.com/
■前スレ
C#, C♯, C＃相談室 Part88 [転載禁止]©2ch.net
peace.2ch.net/test/read.cgi/tech/1437808445/
C#, C♯, C＃相談室 Part89
peace.2ch.net/test/read.cgi/tech/1443271409/
C#, C♯, C＃相談室 Part90
echo.2ch.net/test/read.cgi/tech/1455160063/
■次スレは>>970が建てる事。
建てられない場合は他を指定する事。
- 237 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 10:29:56.40 ID:0bgRfGhz.net]
- >>229
string myfunc(string a){
if(a==null)
return null;
を追加したらスッキリしました！
- 238 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 11:12:00.41 ID:6I7N2mEo.net]
- aってstringだったのか…
余計なことを言いたくなるなあ…
- 239 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 11:15:09.05 ID:ZfUdGYAZ.net]
- スッキリﾜﾛﾀ
どうしてもならジェネリックの拡張メソッドを作っとく手もあったね。
- 240 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 17:50:29.26 ID:t3MBfDke.net]
- nullを返す関数を作ると後々災いの元
- 241 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 17:52:57.62 ID:E8arxXAw.net]
- かと言ってstringで""を返す関数を作っても後々災いの元
- 242 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 17:55:21.80 ID:VKIYWaqI.net]
- >>236
またその話か
それはないよ。
- 243 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 23:03:49.26 ID:0bgRfGhz.net]
- >>236
なんで？
- 244 名前：デフォルトの名無しさん [2016/11/20(日) 00:13:29.86 ID:BknfpFpO.net]
- 暫く使ってみたがWPFというかMVVMはやっぱり良くないな
暫定的にとはいえ不正な状態のオブジェクトを受け入れるってのが致命的にコードを汚くする
カプセル化で状態を保護するのが基本のオブジェクト指向に喧嘩売ってるとしか思えない
- 245 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 00:26:32.91 ID:K2ib4r+U.net]
- >>239
その関数使う使う時に一々nullチェックするの面倒。
それを忘れない保証もどこにもないし。
- 246 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 00:30:59.63 ID:ckE9xegj.net]
- >>241
何という頭の悪さ。
nullを禁止したらnullを返すことで表現していたことを
もっと面倒な別の方法で呼び出し側に伝達する必要が生じるんだけど。
何でこんな簡単なことが分からないのかね。
- 247 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 01:00:26.85 ID:KPo4Qlq+.net]
- FindFirstみたいなメソッドでマッチしない場合にnullじゃないオブジェクトを
返されたとしてもどのみちチェックする必要が出てくる
- 248 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 01:09:39.51 ID:X8MMRSH3.net]
- null返す関数禁止じゃなくてnull代入禁止型にしてくれ
- 249 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 01:27:12.98 ID:K2ib4r+U.net]
- >>242
勉強不足
- 250 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 01:38:16.74 ID:K2ib4r+U.net]
- >>244
C#7.0か8.0に期待。
- 251 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 02:13:42.33 ID:ckE9xegj.net]
- 期待するだけ無駄。
馬鹿じゃなきゃちょっと考えればわかるはずだが、
必ず既定値で初期化されるようにするにしろ初期化なしの変数宣言ができないようにするにしろ、
nullを許容することの弊害とは別のより大きい弊害や利便性の低下を生むだけ。
だいたい、nullを許容することの弊害なんて大半はそれを主張してる奴が勘違いしてるだけだ
- 252 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 02:22:5
]
- [ここ壊れてます]
- 253 名前：9.08 ID:9PtzIqGH.net mailto: 老害臭が半端無いんだが。 []
- [ここ壊れてます]
- 254 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 02:25:15.52 ID:ckE9xegj.net]
- 年齢の問題じゃないね。
馬鹿かそうでないか、それだけの問題
- 255 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 05:58:45.20 ID:2ye3zmI2.net]
- >>244
nullを返す関数や変数にnullを代入する処理をよく使うのですが、
それで混乱した経験も無いのですが、なぜ、
nullを返す関数
変数にnullを代入
に反対する人がいるのでしょうか？
- 256 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 07:22:58.86 ID:pCJ1qvOZ.net]
- >>250
>>241と同じ
- 257 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 08:05:54.92 ID:2ye3zmI2.net]
- >>251
>その関数使う使う時に一々nullチェックするの面倒。
>それを忘れない保証もどこにもないし。
この意味が分からないのですが、関数を使うときにnullチェックする
と言うのは何ですか？
関数がnullを返す場合もあるように自分でそうしているわけだから
何も問題ないと思いますが。
- 258 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 08:15:43.24 ID:pCJ1qvOZ.net]
- >>252
理解できない奴には理解できないからもう気にするな。null禁止にしても同じ問題起きるしｗ
- 259 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 08:27:09.27 ID:2ye3zmI2.net]
- >>253
気になるんです。
教えてください。
- 260 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 08:32:27.43 ID:w/pS54nD.net]
- そもそもこれは戻り値がstring限定の話じゃないの？
普通のオブジェクトでnull禁止はありえないからね
- 261 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 08:43:15.40 ID:pCJ1qvOZ.net]
- >>255
(nullでなく()デフォルト値を入れた空のオブジェクトを返すって考え方もあるからオブジェクトでも同じだよ
そもそも1つの戻り値で関数失敗成功情報まで返そうとするのが間違い
- 262 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 08:47:01.08 ID:3blV6AGf.net]
- 値型は null にならないのでそれで用は足る。面倒なのは、Stringだかが。昔のBASIC の文字列型のように実装した値型を用意すれば解決。
- 263 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 09:29:50.43 ID:2ye3zmI2.net]
- >>257
>面倒なのは、String
C#で文字列を扱っていてnullの扱いで面倒だと感じた経験が
一度もないのですが、Stringでnullがなぜ面倒なのですか？
- 264 名前：デフォルトの名無しさん [2016/11/20(日) 09:42:15.04 ID:BknfpFpO.net]
- nullは情報を捨ててしまうから可読性が低くなる
エラー許容型を作ってそれを使うのが定石
Errorable<string> s = func();
if(s.HasNoError) WriteLine(s.Value);
else WriteLine(s.ErrorMessage);
if(s.NotFound) ...
if(s.AuthError) ...
if(s.FormatError) ...
...
- 265 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 09:59:28.46 ID:Y223jndk.net]
- >>259
> その関数使う使う時に一々nullチェックするの面倒。
> それを忘れない保証もどこにもないし。
全然改善されてないだろ w
てか、その例なら素直に例外使えよ
- 266 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 10:11:47.90 ID:GbOcvoRT.net]
- IsNullアンチパターンみたいだね
- 267 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 10:12:24.08 ID:wbF3tHCA.net]
- >>260
チェックなしでValueにアクセスしたら例外を投げる
Errorableという名前が見えることによってチェックを忘れるということを回避できる
チェックがめんどくさいという怠惰さには手の施しようがないがnullやエラーコードと違ってチェック方法が統一化できる点も優れている
- 268 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 10:27:40.57 ID:9PtzIqGH.net]
- もう一歩踏み込んで、Maybe。
Valueプロパティは、もちろん無し。
- 269 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 10:30:00.58 ID:X8MMRSH3.net]
- 宗教としてC#にアイデンティティを代替している連中(貧乏人ほどオリンピックが好きなのと同じ)なのに
仕様を否定したって聞き入れる訳ないじゃん
ヘジにアントニー・ホーアの言葉をどう考えるか聞いた奴がいるが
なんて答えたか知らないんだろうし
(あるいは、C#に間違いがあってはならないから目をつぶっているか、そもそも英語は読めないか)
- 270 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 10:30:10.23 ID:9PtzIqGH.net]
- >>250
ぼっちで書いてる時は、好きにする宜し。
- 271 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 10:35:26.28 ID:2ye3zmI2.net]
- 文字列の場合にはNullも "" も同じだと思えばいいよね
- 272 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 10:37:02.45 ID:NgPgW0rj.net]
- 参照型とnull許容型は別の概念にするべきだったと言ってるし
現在、null非許容型を破壊的にならないように言語仕様を変えよう(追加しよう)としている。
将来を全て見通せる人は、いないと言う事だよ。
- 273 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 10:38:09.66 ID:Y223jndk.net]
- >>262
> チェックなしでValueにアクセスしたら例外を投げる
ならはじめから例外でいいだろ
> Errorableという名前が見えることによってチェックを忘れるということを回避できる
マジで言ってるの？
チェックする箇所には変数名しか見えないんだが...
まあ IDE でいちいち型を確認すればいいんだろうけど、エラーチェック忘れるような奴はそう言う型の確認も忘れるわけで...
> チェックがめんどくさいという怠惰さには手の施しようがないがnullやエラーコードと違ってチェック方法が統一化できる点も優れている
たぶん思い付きで書いてるんだろうけど例えば Errorable<string> の
> if(s.AuthError) ...
って何を返すの？
自作のクラスで新しいエラー状態をチェックしたい時はどうするの？
いちいち Errorable を派生させたりしたらチェック方法が統一できないしどうするつもり？
- 274 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 10:40:19.54 ID:Y223jndk.net]
- >>266
お前さんがそれでいいならなんの問題もない
- 275 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 10:48:41.71 ID:NgPgW0rj.net]
- >>249
最近は若くても｢老害｣みたいな人が少なくないよね。
新しい事を覚える･勉強するのを嫌がる。
現状のやり方を変えるのを恐れる。
現状維持大好き。
良いか悪いは別問題だけど。
- 276 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 10:58:38.68 ID:wbF3tHCA.net]
- >>268
初めから例外を投げるではチェックのためにtryを書かなければならない
パフォーマンスが悪いしifで分岐する処理を書きたいという場面では構文的に不利で不適切
変数の型が見えなくなるほど長いスコープは普通は書かないので考慮しなくて良い
エラーというのは幾つかの典型的なエラーに分類可能
例であげたようにNotFoundやAuthErrorといった幾つかの典型的なエラーを定義しておけば良い
新しいエラーを定義する必要はない
- 277 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 11:34:52.66 ID:Y223jndk.net]
- >>271
> パフォーマンスが悪いしifで分岐する処理を書きたいという場面では構文的に不利で不適切
まあ、これはいいとして
> 変数の型が見えなくなるほど長いスコープは普通は書かないので考慮しなくて良い
フィールドとかには使えないってことでいいかな？
> エラーというのは幾つかの典型的なエラーに分類可能
へー、すごいね w
> 例であげたようにNotFoundやAuthErrorといった幾つかの典型的なエラーを定義しておけば良い
で、Errorable<string> の AuthError ってなにさ
> 新しいエラーを定義する必要はない
自称エスパーのお前はそうなんだろうね w
- 278 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 11:43:29.92 ID:lYnhz1xv.net]
- null非許容型が追加されたら便利だなーとは思う
「nullをなくせ」という意見にはまったく賛同できないが
エラー許容型は、エラーの種類を enum で返すプロパティを付けたものをよく作る
（エラー種類ごとにプロパティ作るようなことはしない）
でも、nullで済む場合も多いんだよね
- 279 名前：デフォルトの名無しさん [2016/11/20(日) 11:43:53.85 ID:kKwT4/wt.net]
- >>272
はぁ
今は返り値の話をしているんだろ
そもそもオブジェクトの内部状態であるフィールドがエラーを受け入れるのが間違いって基本的なことになんで思い至らないのか
すごいっていうか、常識
人間がどんだけエラー処理と付き合ってきたと思ってるんだ？
AuthErrorは認証、認可のエラー
２chの書き込みだから横着して省略したがこれらは普通は別にする
nullを見ただけでエラー内容がわかる歴史上類を見ないほどに強力なエスパーの君にはかなわないよ
プログラマにしておくのは勿体無いから新しい宗教でも立ち上げることをお勧めするよ
- 280 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 11:47:36.19 ID:pCJ1qvOZ.net]
- 変数にエラーコードを入れるっていう発想がもうｗ
- 281 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 11:47:38.25 ID:GbOcvoRT.net]
- >>266
その考えの場合はnullじゃなくて、""を返すのも良いかもね。
- 282 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 11:56:23.29 ID:Y223jndk.net]
- >>274
> そもそもオブジェクトの内部状態であるフィールドがエラーを受け入れるのが間違いって基本的なことになんで思い至らないのか
え？
オレオレスタイルをどや顔で言われても困るんだが w
> これらは普通は別にする
結局 Errorable<string> と Errorable<database> は別に作るってことかよ...
チェック方法が統一出来るとかほざいてたのにね w
- 283 名前：デフォルトの名無しさん [2016/11/20(日) 12:10:20.24 ID:kKwT4/wt.net]
- >>277
はぁ
オレオレスタイルではなくオブジェクト指向の基本
別に作らないよ
君は超人的エスパーだから何をどう考えてそういう答えにたどり着いたのか常人にはちょっと理解しがたいんだ
これからはそのことを考慮して常人にもわかるように丁寧に意見して欲しい
- 284 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:10:41.53 ID:zFrmc+0J.net]
- >>266
オラクルですね
- 285 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:23:00.48 ID:L/fyhMFX.net]
- >>277
みっともないから、もう止めとけ。
- 286 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:30:03.99 ID:Y223jndk.net]
- >>278
オレオレスタイルは宗教だろうから教祖さんと争う気はないよ w
で、
> これらは普通は別にする
の意味を説明してみ
- 287 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:30:42.62 ID:Y223jndk.net]
- >>280
お前がな w
- 288 名前：デフォルトの名無しさん [2016/11/20(日) 12:37:01.76 ID:kKwT4/wt.net]
- >>281
この文脈でauth errorと省略せずにauthentication errorとauthorization errorに分けるという意味以外に何があるんだ?
君は何をどう考えてErrorable<string>とErrorable<database>は別に作るという考えに到達したの?
ジェネリック型の新しい使い方を編み出したの?
ハイレベルすぎてついていけないよ
一体何段階思考手続きをスキップできればこの境地にたどり着けるのか
- 289 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:38:10.81 ID:aCqfb5MR.net]
- 数字の0が無かった時代に0の発明を否定する人みたいだな。
- 290 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:43:24.41 ID:h3zFIm5r.net]
- 何度も言うけどnullを追放したって問題Aが別の問題Bに置き換わるだけ。
そして普通に考えれば問題Bの悪質性はAより大きくなる場合の方が多いだろう。
nullガーって吠えてる馬鹿って何でこの程度のことが分からんかね。
(a) 値がnullであることで問題が顕在化した
からといって
(b) nullの存在が問題の原因
であるとは限らない。
この程度のことも分からない奴はプログラマ辞めろよ本当
- 291 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:45:41.10 ID:2ye3zmI2.net]
- >>279
そう、
オレオレスタイルではなてく
オラクルスタイルだ。
- 292 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:53:48.90 ID:Jza3G5L3.net]
- 結局メソッドがエラーを返せるようにするにはどうするのが一番いいの？
- 293 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:54:07.99 ID:Y223jndk.net]
- >>283
> この文脈でauth errorと省略せずにauthentication errorとauthorization errorに分けるという意味以外に何があるんだ?
そんな話は全くしてないが？
そんなのどうでもいいから
>> で、Errorable<string> の AuthError ってなにさ
の答えを書けよ w
- 294 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:54:12.13 ID:L/fyhMFX.net]
- まさに、井の中の蛙 (´・ω・｀)
- 295 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:57:21.73 ID:L/fyhMFX.net]
- >>287
１つの手段は、エラー種類と｢値｣のタプルを返す。
これだと、エラー処理を強制は出来んけどね。
- 296 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:57:41.85 ID:Y223jndk.net]
- >>289
上から目線で意味のないこと言ってるけどどうしたの？
ここ仮にも技術系の板だから話に加われないなら黙っていてくれるとありがたいんだが
- 297 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 17:21:32.25 ID:XK08TpAy.net]
- エラーはほとんどの場合例外でいいよ
でも例外が使えない場面もあるんだよなぁ
- 298 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 18:54:25.34 ID:34y1pXq0.net]
- >>287
エラーと言ってもいろんなレイヤーでいろんな事があるわけで
結論としてはケースバイケースでどれが一番とか決めれない
これを理解できずに単一の方法ですべてやろうとするからおかしな話になるわけで
まあ、宗教論はその宗旨に納得できる点がある場合もあるけど、他の宗教を認めないのがなぁ
- 299 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 19:03:56.76 ID:eCa9a5kv.net]
- 例外を投げないパターンはここらへんを読むといいんじゃない？
一般的とは行かなくても、オレオレではない
faithandbrave.hateblo.jp/entry/2014/05/30/153325
ufcpp.net/blog/2016/11/nullproblem/
www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4015.pdf
- 300 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 19:18:59.75 ID:V9rEuhsa.net]
- nullable-likeの提案は良いね
- 301 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 19:26:56.04 ID:w/pS54nD.net]
- nullを排除するために、何故ここまで複雑に作る必要があるのか理解出来ん
普通にnull使えよｗ
- 302 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 19:31:08.12 ID:34y1pXq0.net]
- 単にnullの取り扱いから、例外処理についてに話が拡大してるからな
- 303 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 19:46:59.71 ID:ELwGw4ow.net]
- null排除派はごく一部いるけど市民権を得てない
メリットが薄いから
3 == i と言う書き方みたいにこだわる人だけこだわる
- 304 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 20:23:01.03 ID:JNgwCyth.net]
- 今後iOS開発の主流になるだろうSwiftがnull非許容ベースだから
将来的には分からないかもよ
- 305 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 20:32:56.89 ID:ixFUSBgZ.net]
- 信者にそんな話しても無駄
- 306 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 20:42:02.87 ID:RSV7nlYW.net]
- null あってもいいって言ってるのはなきゃなでも構わない人が大半じゃないかと思う。
Swift が非許容でそれを使う必要があるなら、それの流儀でなんの苦もなく対応しそう。
そんなことに拘ってるのはオレオレな一部の人だけじゃねーのかなぁ。。
- 307 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 21:02:17.68 ID:2AHf550w.net]
- 異教徒にそんな話しても無駄
- 308 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 22:12:22.04 ID:eCa9a5kv.net]
- >>296
それを言い出すとなにも言語仕様がいじれなくなっちゃう
Javaとかは進化が停滞して今必死に挽回してるし
もちろん、実装や文法の複雑さと利点を天秤にかけるのは常にしてるので、Roslynのissueとかを見てみると良いよ。
もっと変なのもたくさんある
qiita.com/koher/items/e4835bd429b88809ab33
を見るとわかるが、実際に各言語がnull安全に取り組んでる
- 309 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 23:25:18.49 ID:OrHcogku.net]
- null安全ねえw
そういう発想をする人ってよくいう「例外を握りつぶす」コードを書いちゃうタイプなんだろうなとは思うわ。
言いたいことは理解できるが全く同意はできない。
それはただの錯誤だからな。
安全どころか、nullであれば容易に発見できたバグをわざわざ発見困難にするだけ。
何がうれしいんだそんなの。
- 310 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 00:24:21.34 ID:hlf3slD2.net]
- ScalaのOption使ってみた感想
・今までは無効な値(null)を返す可能性がある事は、ドキュメントを読まないと分からなかったけど定義だけで分かるから便利
・分解が色々な方法で出来て便利
まあなくても何とかなるけど、あれば便利程度
- 311 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 01:11:30.92 ID:fZvEw43o.net]
- F#にもoptionあるけど死ぬ程便利だわw
先ず、エラーを握り潰す事が出来ない。
ドキュメントを読む必要が無い。
monadとして扱うと、一々ifで分岐書く手間がなくなる。
eitherまで踏み込めば、検査例外云々で議論する事自体が馬鹿らしくなる。
面倒くさいけどねw
C#のint?を使った事ある人には解ると思う。
コンパイラに事前チェックをしてもらえる有り難みが。
機械に解る単純作業？に対して、人間が一々苦労する馬鹿らしさが。
- 312 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 01:16:13.30 ID:fZvEw43o.net]
- それから、初心者に対してこそ効果抜群だよ。
｢そう書く｣事しか出来ないから。
強制出来るから。
- 313 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 01:34:00.10 ID:CO+aVjyU.net]
- 検査例外も出たときは素晴らしい機能だって絶賛されてたような気がするなぁ
- 314 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 02:03:53.66 ID:n+GSTHBL.net]
- 検査例外は他に誰も採用しなかったけど
Optionalはこぞって採用されているという決定的な違いがある
- 315 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 02:04:20.65 ID:n+GSTHBL.net]
- あ、ごめん
C#perにそんなこと言っても分からないよね(苦笑)
- 316 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 11:12:26.42 ID:Ka0MFQDU.net]
- ん？Optional？VBの話？
- 317 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 11:41:21.77 ID:hLpmxTjl.net]
- グラディウスだろ
- 318 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 17:31:28.36 ID:fZvEw43o.net]
- >>310
このスレにもいるような｢老害｣は少数派だよ
と信じたい。
- 319 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 20:45:41.48 ID:HLjti5+r.net]
- 実際、エラーの扱いは時代によって色々変わってきてるからね
null安全の手法はこれからの主流になっていくのかもしれない
そんで、また数年後には新しいやり方に置き換えられるんだろう
- 320 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 21:06:27.63 ID:4A1pLeCT.net]
- エラーの扱いじゃなくてヒューマンエラーを未然に防ぐのが意図でしょnull安全ってのは。
その意図は認めるけど、null安全がその目的に対して合理的とは全く思わんがね
- 321 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 21:15:05.95 ID:fZvEw43o.net]
- option型とnull安全は重なってる部分もあるけど、意味としてズレてる部分もある。
例えば、C#の値型でもoption型は有意義な訳で。
- 322 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 22:30:24.18 ID:wfKopLFy.net]
- サードパーティーライブラリーを使えない前提でオブジェクトのマッピングを手軽に行うにはなにを使う?
パフォーマンスはあまり気にしていない
同名同型のプロパティをマッピングできれば十分
今のところシリアライザーで誤魔化してる感じ
- 323 名前：デフォルトの名無しさん mailto:sage [2016/11/22(火) 00:16:30.64 ID:QATijxTL.net]
- null安全よりstring?.lengthの方が合理的に見えるわ
最初からならともかく、ここまで普及したC#で今更取り入れて定着するのは難しいよな
- 324 名前：デフォルトの名無しさん mailto:sage [2016/11/22(火) 06:51:43.66 ID:y8FHZWuV.net]
- >>318
> 最初からならともかく、ここまで普及したC#で今更取り入れて定着するのは難しいよな
これには同意するけど
> null安全よりstring?.lengthの方が合理的に見えるわ
これはないわ
string が null になる可能性がないなら普通に string.length って書いた方がエラーが早期にわかるからデバッグも楽だし
- 325 名前：デフォルトの名無しさん mailto:sage [2016/11/22(火) 07:50:04.91 ID:vhsrXRxU.net]
- ?.もnull安全の一環な気はする。
ちなみに、null非許容型導入の影響で、?.を使っていない箇所は全てwarning扱いになる話もあったりする。
- 326 名前：デフォルトの名無しさん mailto:sage [2016/11/22(火) 13:10:29.71 ID:bfu4FZ0h.net]
- string?.length
これって式の左辺に何書くの？
int? hoge
とか？
で結局hoge==nullとか聞いちゃうの？
?.演算子は参照型と値型のペアでは使いにくいし分かりにくいと思う
- 327 名前：デフォルトの名無しさん mailto:sage [2016/11/22(火) 17:09:05.83 ID:EJKURZYz.net]
- 君ら一体何を議論してるの？
分かりやすく解説してくれ
- 328 名前：デフォルトの名無しさん mailto:sage [2016/11/22(火) 17:11:14.76 ID:VnsYzvlz.net]
- Optionalの是非というか使い所の話でないの？
- 329 名前：デフォルトの名無しさん mailto:sage [2016/11/22(火) 19:57:46.66 ID:vhsrXRxU.net]
- >>321
例えば
int len = str?.Length ?? 0;
- 330 名前：デフォルトの名無しさん mailto:sage [2016/11/22(火) 20:13:33.64 ID:ga0p/qoV.net]
- C++の参照は良いものだった
- 331 名前：デフォルトの名無しさん mailto:sage [2016/11/23(水) 10:56:47.19 ID:Sj0D9A4Y.net]
- >>325
なんで過去形？
- 332 名前：デフォルトの名無しさん mailto:sage [2016/11/23(水) 11:55:24.93 ID:Sj0D9A4Y.net]
- stackoverflow.com/questions/22595655/how-to-do-a-dictionary-reverse-lookup
このページで
dictionary.FirstOrDefault
とやっていますがディクショナリーにFirstOrDefaultを
やるとなぜこういう結果になるのですか？
- 333 名前：デフォルトの名無しさん mailto:sage [2016/11/23(水) 13:27:10.63 ID:GLuKyrfg.net]
- >>327
何を「何故」と思ってるか分からん
- 334 名前：デフォルトの名無しさん mailto:sage [2016/11/23(水) 18:46:09.31 ID:QXjR6WNV.net]
- >>327
Dictionaryは、IEnumerable<KeyValuePair>を実装しているから。
- 335 名前：デフォルトの名無しさん mailto:sage [2016/11/23(水) 19:25:46.80 ID:Sj0D9A4Y.net]
- >>328
FirstOrDefault って最初の要素を取って来るんじゃないんですか？
何故全ての要素をループ出来るんですか？
- 336 名前：デフォルトの名無しさん mailto:sage [2016/11/23(水) 19:44:53.91 ID:GLuKyrfg.net]
- >>330
『引数の条件に一致した』最初の要素ね。
内部的には列挙子で探してるよ。
- 337 名前：デフォルトの名無しさん mailto:sage [2016/11/23(水) 19:48:19.93 ID:4RFw+AHR.net]
- 列挙子＝enum ・・・
|
 |
