Kotlin 6

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2019/06/22(土) 15:59:57.23ID:zj+KJbMh
JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう

※前スレ
Kotlin 5
https://mevius.5ch.net/test/read.cgi/tech/1544268581/
2020/03/20(金) 01:48:47.36ID:405ti7Ej
>>797
「親が有るかどうか」
という一つのパラメータだけなら、まだ良いが、
「メニューオブジェクトを渡すか渡さないかでメニューが付くかどうか分ける」
なども付いたりすれば、組み合わせ爆発が起きるため、関数を完全に分けてしまうのは非常に非効率で危険なプログラミングとなる。
2020/03/20(金) 01:52:10.51ID:i2c+AgK7
共通化が必要ならNullObjectの多態でも関数型でも使えばいいよ

C言語時代からアップデートされてない知識でモダン言語でのプラクティスを説こうとしているのが謎だよ
タイムスリップしたお侍が自衛隊に兵法を指南するような冗談だよ
2020/03/20(金) 01:56:11.47ID:i2c+AgK7
組み合わせ爆発についてはデフォルト引数使えばよろし
2020/03/20(金) 01:59:36.15ID:405ti7Ej
>>800
そのデフォルト引数には、NULLかNullObjectを指定するしかないはず。
なんで、NULLで済むのにNullObjectを使うの。
それで安全になるのか？
2020/03/20(金) 02:03:02.63ID:405ti7Ej
>>799
では、>>793の例を NullObjectや多態を使って分かり易くて安全に書き直してみてください。
2020/03/20(金) 02:49:45.65ID:4pMtFWMQ
>>796
すべてのウインドウはRootWindow配下とするみたいなルールを設定して、親のないウインドウは禁止するればいい。

linuxのプロセスが必ずinit配下になるのと同じ感じ。
2020/03/20(金) 02:54:28.27ID:405ti7Ej
>>803
それは可能だけど、グラフィックのFrameBufferの容量が大きいので、
デスクトップに浮いているWindowの場合にChildWindowと同じ処理をしたのでは
メモリーの無駄使いになることがあったり、
デスクトップに浮いているWindowとChildWindowとでは動作がかなり違っていたり
することが多いので初期化段階から if 文で場合分けしないと無理が有る事が多い。

だから、そのような「統一した考え」では結局は、効率が下がるために
実際には駄目プログラムとなる。
2020/03/20(金) 03:01:28.97ID:405ti7Ej
>>804
さらに付け加えるなら、RootWindow のオブジェクトの名前を「覚えるのが面倒」
だったり、打ち込むのが長くなって大変と言う事情もある。
例えば、Windowの場合には、「DesktopWindow」という名前で、
Menuオブジェクトが無い場合には、「MenuNull」みたいな名前となる。
しかし実際にはこんな簡単な名前で無い事が多いので、マニュアルをいちいち調べ
直す手間がいる。
一方、NULLだといろんな場面全てNULLなので、覚えることが少なくて済むし、
打ち込むにも4文字で済むので楽。
関数を呼び出す際も短いので一行で書ける場合が多くなり、見易い。
806デフォルトの名無しさん
垢版 |
2020/03/20(金) 05:05:17.32ID:Edy1QoAW
>>793
Kotlin ならこんな風にすれば良いんじゃないの?

fun myCreateWindow(parent: CWnd? = null): CWnd = if (parent == null) 親なし上位Window作成 else parentの子Window作成

nullable がどうしても嫌ならこうするか。

fun myCreateWindow(parent: CWnd = 親なし上位Window): CWnd = if (parent != 親なし上位Window) parentの子Window作成 else parent
2020/03/20(金) 06:32:14.26ID:Oo7Eeggj
言語やベンチマークの議論一般にいえることだけど、自分の有利な土俵に引っ張りこめば何とでも主張できる。

Kotlinは>>805向けには作られていない。というだけのこと。
2020/03/20(金) 06:53:01.35ID:4pMtFWMQ
>>804
そこはクラス分けてポリモーフィズムで上手くやろうよ

先のウインドウタイトルといい、例が良くないんでは？
2020/03/20(金) 07:53:37.14ID:i2c+AgK7
>>801
書かれてたサンプルコードでは真っ先に分岐が入ってたから「この場合は」オーバーロードかメソッド分割がベターと回答した
後付けされた条件を加味するなら>>806のnullable型がいい
privateな処理内で局所的にnullabeを使うことに異論はない
Kotlinならヌルポが出ないから安全

覚えるのが面倒ということまで気にする公開APIなら親にnullを指定すると親無しになるというルールを覚えさせるよりも
親の引数を省略可能にするかメソッド名を用途別に分けてクラス内で処理を共通化した方が使いやすい

nullは単一なので楽という話は、nullは単一なのでいろんな意味がまぜこぜに使われ区別できないという裏返しでもある
variantは型がないので楽、グローバル変数は楽、staticは楽というのに通じる
2020/03/20(金) 07:58:22.42ID:i2c+AgK7
メソッド引数にnullを与えたときヌルポが出るのかトップレベルウィンドウになるのかドキュメントを読まないと判別できない公開APIは残念
省略時デフォルトとして内部的に使うのとはまた違う
2020/03/20(金) 09:18:27.10ID:CQQp7Y75
Kotlin では、プログラマーが自分で、null を判断したら、ダメ！
null チェックを書かない人がいるから、バグが残る

C++ で言えば、スマートポインターみたいなものを使って、
自動的に判断するのが正しい

どこかで、nullチェックをして、nullじゃなければ、
null許容型を使わないように書く
2020/03/20(金) 10:12:13.96ID:1hj/B9bx
>>811
だったらそもそも静的な型がない上に基本的にプログラマが明示的な型チェックもしないことが普通なRubyは、
Kotlinで常にnull許容でチェックも一切しない以上に遥かにバグが残るってことになる(実際そう)なのだが、
自分で意味分かって言ってんのかなこいつ
2020/03/20(金) 10:31:11.84ID:EaZGEhh2
「真っ先に条件分岐が入ってたから」

はどこいったんだろう
適当やな..
2020/03/20(金) 10:38:58.93ID:EaZGEhh2
それにそもそもオーバーロードかメソッド分割がベターとかいってるが、設定するメソッドじゃなくて現在設定されてる値を取得するメソッドまたはプロパティを追加するときはいったいどんな値返すんだ??

普通に元からnullでいいだろ
2020/03/20(金) 10:47:13.64ID:IqcuAu3D
>>814
nullable使わないなら異なる型を返すんだよ。nullable含め場合分けを型で強制することで不必要なバグが入り込む余地を無くすのがnull safetyな言語の流儀
2020/03/20(金) 11:02:35.25ID:EaZGEhh2
そういう他人をわざと変な方向に導こうとしてもひっかからんしつまらんから..
2020/03/20(金) 13:05:07.29ID:405ti7Ej
>>808
>そこはクラス分けてポリモーフィズムで上手くやろうよ
具体的にポリモーフィオズムでどうやれば分かり易く書き直せるか教えてください。
2020/03/20(金) 13:55:01.27ID:i2c+AgK7
>>813
どこ行ったの意味がわからない
どこに矛盾を感じたの？

>>814
俺はメリットデメリット考慮してnullableも含めて最適なものを選ぶのがいいと言ってるんだよ
前提が変わればnullableが簡潔で具合いいところもあるだろ
>>794のサンプルでnullabeを選ぶ理由ある？
2020/03/20(金) 14:01:35.66ID:i2c+AgK7
>>818
訂正
デフォルト引数の初期値をnullとして使うケースは良かった
理由は上で書いた通り
2020/03/20(金) 14:39:06.40ID:405ti7Ej
そもそも null はそんなに危険ではない。
そのまま使おうとすれば、Windowsの場合だと、Release版ですらほぼ100%一般保護例外が生じるからどこで問題がおきているかも分かるし。
2020/03/20(金) 14:40:27.30ID:405ti7Ej
nullが危険といっている人は、MMUを使ってない化石の様なOSでの経験に基づくものなのかな。
2020/03/20(金) 14:47:03.13ID:405ti7Ej
if で場合分けせずに、オブジェクトのclassの仮想関数で場合分けさせると言う考え方
は時々聞くが、それはすべてをオブジェクト指向に置き換えれば上手く行くと言う根拠
のない浅はかな考え方だ。
経験を積むとその思想は間違いであることが分かってくる。
2020/03/20(金) 15:49:29.05ID:i2c+AgK7
ページ違反が起きて特定に悩まされたのが昭和
一般保護例外なりヌルポなりの発生元ステップをテストで洗い出すのが平成
モダン言語ではコンパイル時に検出するので品質もコストも優位

老人は自らの成功体験に頼るので新しく良いものが現れても知識体系に取り入れることが難しく適材適所の選択ができない
2020/03/20(金) 16:01:15.37ID:5BxgCAjb
祝日になった途端荒れだした
2020/03/20(金) 16:45:35.12ID:3oKoD+ta
能無しJAVAコーダーが暴れてるんだろ
2020/03/20(金) 16:50:44.74ID:405ti7Ej
>>823
むしろ、OOPでやればなんでも上手く行くと思い込んでいる頭の固い馬鹿にしか思えんが。
2020/03/20(金) 17:03:18.75ID:lyFWLrjP
Javaカスイライラで草
プログラマのくせに新しいもの嫌いとか致命的にセンスないだろw
さっさとやめろよこの業界w
2020/03/20(金) 17:08:13.91ID:3oKoD+ta
>>827
ほとんどはコーダーやろ
2020/03/20(金) 17:12:54.71ID:405ti7Ej
新しくても駄目なものは駄目。
新しければいいと思うな。
若ければ年上に勝てると思うな。
2020/03/20(金) 18:03:14.01ID:NjO7svfB
老人とか関係ないな。
愚者は経験に学ぶ
それだけ
831デフォルトの名無しさん
垢版 |
2020/03/20(金) 18:18:29.68ID:405ti7Ej
おまえが愚者だ。
2020/03/20(金) 19:36:44.38ID:lyFWLrjP
>>828
今時厳密にコーダープログラマーをわけてる現場なんかないだろwクソ老害か？w
2020/03/20(金) 19:37:18.52ID:lyFWLrjP
>>829
老害イライラで草
顔真っ赤にしてる暇あったらkotlinの勉強しようなwww
2020/03/20(金) 19:46:41.44ID:405ti7Ej
>>833
Javaはブームとなるほど、当時としてはちょっと革新的な言語だった。
Kotlinは全然違う。
2020/03/20(金) 21:17:36.75ID:3oKoD+ta
>>832
君が派遣されてるドカタ現場ではそうなんだね
2020/03/20(金) 21:21:57.46ID:6BEgHG50
何でお前らすぐに不毛な煽りあい始めるんだ
2020/03/20(金) 21:26:00.38ID:UGdtYAWR
nullセーフもoopも嫌いならgoがオススメですよ
2020/03/20(金) 21:28:58.30ID:lyFWLrjP
>>835
君が派遣されてるクソ現場は下流しかやってないから律儀にフロントとバックでコーダープログラマー分けてるんだねw
普通上流の仕事してたらそんな底辺下流の扱いなんか厳密に分けてないよwwwww
勉強になったねえ w
2020/03/20(金) 21:50:19.69ID:Oo7Eeggj
>>829
年寄りだったのか。
若い頃に苦労して身につけたテクニックが、言語仕様でカバーされて誰でも実践できるようになって、
脅かされている自分のアイデンティティを守るために必死になっている、ってところかな。
2020/03/20(金) 23:35:23.46ID:405ti7Ej
>>839
この板に居るようなパンチカード(?)を語るようなほどの年寄りではない。
NullObjectでNULLを代用することが、
「言語仕様で誰でも実践できるようになって、自分のアイデンティティーが脅かされる」
に該当するとはとても思えない。
2020/03/21(土) 00:05:57.23ID:5V8tQPWW
パンチカード載せてる台車ひっくり返したら大変
2020/03/21(土) 06:24:08.00ID:JAKzE64M
>>840
> この板に居るようなパンチカード(?)を語るようなほどの年寄りではない。
この板にパンチカードなんて単語一度も出てきてないけど誰のこと?
パンチカード世代ではないにしても、NULLを駆使するのが美しいテクニックだった時代の年寄りなんでしょ?
相手の主張を反論しやすいように歪曲するのはやめた方がいいですよ。

>NullObjectでNULLを代用することが、
「NullObjectでNULLを代用すること」はKotlinの言語仕様でないから、
そのように受け取ったのなら、Kotlinのコンセプトを理解していないか、
相手の主張を反論しやすいように歪曲する癖があるかのどちらか。

>>840が対話の成立しない相手であることが証明されたので
>>840の回答には大変満足しております。ありがとうございました。
2020/03/21(土) 09:04:23.03ID:Nklv0DXu
なんだ、親無しWindow を、null にしただけか。
確かに、そういうAPI があるけど、マネしない方がよい

それって、0 でも空文字列でも、何でもよいわけでしょ。
そうい所に、nullを使うのはおかしい

nullは、ヌルポだけに限定すべき！
異なる意味で使ってはならない！

使い方を文章に書いた時にも、
引数がnullなら、親無しWindowになりますというのも、ちょっとおかしい

そういう用途には、デフォルト引数！
2020/03/21(土) 09:36:51.55ID:oUFNTFet
>>820
それどっちかというと Windows 独自の文化だと思う
たまに Windows 系の助っ人に行ってコンソールに例外出まくりなのみてビビるよ
2020/03/21(土) 09:44:12.11ID:JAKzE64M
>>843
nullは存在しないことを意味すると考えれば、あながち間違いでもないと思うし、
デフォルト引数を使うにしてもデフォルト値はNullObjectになるだろうし。

というのは置くとして>>842で述べたように>>840にこれ以上構わないほうがいいと思うんだが。
2020/03/21(土) 09:55:22.84ID:3uF/mjPQ
俺が老人という言葉を使ったのは実年齢のことではなく振る舞いだよ
Kotlinのコンセプトを理解してないどころか学ぶ気すらない
C++でサンプルを提示する辺りJavaを知っているかすら怪しい
自分のアイデンティティーを脅かされるという自覚はなく、わざわざ下らないものの詳細を学ばなくても俺には経験上わかるんだという老人特有の驕りが見える
全貌が見えてないから議論が噛み合わない

このスレにはnullは一切使わずにNullObjectを使うべきと主張する層とnullableは安全とする層と適材適所で使うという層がいて、この老人にとっては全員敵であり区別できないのだろう
NullObjectはJavaでは効果的なプラクティスだったけどKotlinではStateパターンのような役割でないとさほど輝かないと俺は思う
KotlinでNullObjectが常にnull(able)の良き代替になるなんて誰も提示できないはず
この老人がその一点に拘り他を無視する限りやっぱり俺は正しいんだと信じ続けるだろうな
2020/03/21(土) 10:05:31.48ID:SrebAl5K
若い衆はほんと何がいいたいんだかわからん
2020/03/21(土) 10:12:24.90ID:3uF/mjPQ
>>845
あながち間違いでないことと良いAPIであることには隔たりがあると思うよ
参考としてはJavaが提供しているライブラリにおいてnullを指定してくださいというメソッドよりもオーバーロードを提供しているメソッドの方が多い
ウィンドウの例だけでなく一般化して考えると、引数のデフォルト値として空の関数を与えて綺麗に書けるケースも多い
メソッドごとにnullを渡すべきなのか空の関数を渡すべきなのかNullObjectがあるのかを考えず、引数を省略するというシグネチャーで判別可能な一貫した利用ができるのは優れたメソッド設計だと思う
2020/03/21(土) 11:44:22.68ID:oUFNTFet
爺さんが引数に null 渡す例出したのに釣られちゃってるけど
Javaでも戻り値に null かオブジェクト返す API は普通にあるからね
これは NullObject か nullable に修正したい
850デフォルトの名無しさん
垢版 |
2020/03/21(土) 12:37:46.26ID:R4utYKoB
プログラマーの気持ち悪い部分をいい感じに体現してくれてる
ここであれこれ書いてもぬかに釘
noteかブログにでも書いておけ
2020/03/21(土) 14:00:49.01ID:txJMIm7g
なんでも古い古いと言っていれば、どんなに駄目でも新しい言語や若い人が有利になってしまう法則。
2020/03/22(日) 04:45:41.69ID:HvrypJyW
引数の個数や型だけが異なる「関数の多態性」を行うと、プログラムが間違い易くなる。
なぜなら型や引数の個数の書き間違いをコンパイラが報告してくれなくなることがあるから。
C/C++で型が導入されたのもそういう間違いをコンパイラに発見してもらうためも有ったが、それが働きにくくなってしまう。
853デフォルトの名無しさん
垢版 |
2020/03/22(日) 04:50:38.77ID:HvrypJyW
>>852
一つの関数名に引数の型や個数が異なる関数が10種類くらい多重定義されていたとする。
これを使ったプログラムする際には、マニュアルを見、関数名だけでなく引数も非常に正確に書かなくてはならなくなる。
型や引数の順序や個数などが僅かでも間違っていると、自分が思っていたのとは違う定義のものが呼び出されてしまうことになるが、それでも「合法」になってしまうのでコンパイラがエラーを出してくれない。
また、後から動作を調べようと思ってマニュアルを見たときにも、見間違いで間違った定義の部分の説明を読んでしまう現象が生じ易くなる。
2020/03/22(日) 04:56:18.54ID:HvrypJyW
>>853
func(1,2);
と書いたつもりで、タイプミスなどで
func(1,2,0);
と書いたとしよう。
func()が多重定義されていない場合なら、コンパイラがエラーを出してくれる。
ところが、func()が多重定義されてしまっている場合、たまたま、3つの整数引数の定義があった場合、自分の思ったのとはかなり違う動作の関数なのに、コンパイラが何もエラーを出してくれなくなってしまうことが有り得る。

それから、知らず知らずに「引数の自動型変換」機能が働いてしまうことが有り得る。
それと関数の多重定義の両方が組み合わされると、自分が思っていたのとはかなり
違う動作の関数が間違って呼び出されることになっていても、気づくことができない。
本当はどの関数が呼び出されているのかが分からず、どんなにチェックしても原因が分からない難しいバグが入ってしまうことになるかもしれない。
2020/03/22(日) 05:13:54.89ID:TNUWFKUe
あーウゼー
2020/03/22(日) 08:47:08.62ID:sfJQKmPV
技術的な話でスレが進むのは、過疎ってるよりは良いことだよ
ほぼ読んでないから内容は知らんけど
2020/03/22(日) 09:31:29.37ID:nwybfWiz
>>854
その話は、引数爆発は嫌だ、じゃあデフォルト引数使え、で解決してるだろ
さらに付け加えるなら名前付き引数も使え
そのあたりのCやJava時代の弱点をKotlinやC#は克服済みだ
あと多重定義は多態とは呼ばない
2020/03/22(日) 09:32:27.12ID:nwybfWiz
>>854
たまたま同じ型ばかりを引数にとる関数で順番を間違えるヒューマンエラーには配慮できるのに、nullを多用したときに誰かがミスして実行時エラーが多発するリスクに目を向けないのは何故？
2020/03/22(日) 09:58:58.91ID:CQOUf5Rv
>>857
>あと多重定義は多態とは呼ばない

異なる型に対する多重定義は多態の一種だよ
2020/03/22(日) 11:22:24.81ID:nwybfWiz
>>859
すまんアドホック多相だね
861デフォルトの名無しさん
垢版 |
2020/03/22(日) 11:43:59.28ID:F4lre3ad
>>853
ほんそれ
同じように思ってた人が居て良かった
2020/03/22(日) 12:55:36.51ID:q5xwUBc3
>>853
混同するのが危険なほど挙動が違うのなら、そもそも同じ関数名を使うべきじゃない。
関数・クラス設計における命名規則の問題だろ。言語設計(javaのヌルポ)の問題と関係ない。

この主張が、なんで型なしnullのマジックナンバー利用の肯定に繋がると考えているの？
2020/03/22(日) 15:36:31.56ID:HvrypJyW
>>857
「ポリモーフィズムは次のようないくつかの種類に分けられる：

・アドホック多相（Ad hoc polymorphism）：ある関数が、異なる型の引数に対してそれぞれ異なる実装を持つ場合。多くのプログラミング言語で関数の多重定義としてサポートされる。
・XXXX
・XXXX
・・・
」
864デフォルトの名無しさん
垢版 |
2020/03/22(日) 15:39:40.53ID:HvrypJyW
>>858
親Windowのポインタを受け取る引数にNULLとした場合、意味は分かり易い。
「親がない」こと以外に意味を取りようがないから。
同様に、メニューオブジェクトへのポインタをNULLとした場合も、
「メニューがない」こと以外に意味を取りようがないので分かり易い。

それに比べて、関数を多重定義した場合には、ミスによってとんでもない動作をしてしまうことが有り得る。
2020/03/22(日) 20:16:05.50ID:nwybfWiz
>>864
結局、関数の実装者がミスってnull参照エラーを起こすリスクは見えてないのか
2020/03/23(月) 01:38:55.49ID:bf1cRh+B
>>865
この例の場合、NULLにすると、それぞれ親Windowがない場合、Menuがない場合で、どちらも重要なので、さすがにテストしてあるはずなのだ。
この例に限らず、引数にNULLを指定する場合は、そのような「重要な変化」をもたらす事が多いので、必ずテスト済みの場合が多い故に安全なことが圧倒的多い。
2020/03/23(月) 02:26:57.24ID:dalJ4OEg
>>864
何を言いたいのか全然わからん。

NULLの利点は親Windowの指定方法だと言っているのに、
>>854だと全く関係のない関数funcでoverloadに問題があると言っている。
自分の主張に沿うようにいいとこ取りしすぎ。

同じケースでNULL利用の利点とoverloadの欠点を比較しろよ。

>親Windowのポインタを受け取る引数にNULLとした場合、意味は分かり易い。
nullよりも"NoWindow"というNullObjectを定義して使ったほうが意味はわかりやすい。
なんでnullを使わなきゃいけないのかね？
2020/03/23(月) 02:48:11.59ID:bf1cRh+B
>>867
後半、NULLで十分なのに敢えて、NoWindow なんてオブジェクトを定義する必要
を感じない。それでバグが減るわけでもないし。
2020/03/23(月) 03:14:15.98ID:6F6bSuZt
>>866
それは言い換えると、nullを安全に使えるのはテストのパターン漏れがあり得ないような重要な変化があるところに限られ、それ以外で使うと安全とは言えないってことだよな
「安全なことが多い」ってのは危険は残っていると認めてるね
「さすがに〜はず」ってのは希望的観測だし、最後の文だけ「圧倒的」を付け足したのも論拠不足だよな
人は多重定義で引数順を間違えるような凡ミスをすると理解できているんだ
では人が重要ではない甘いところでnullを不用意に使ってしまうミスは当然あるよな
2020/03/23(月) 08:20:48.10ID:E0UAbPRX
>>868
前半の準備できてから議論続けてね。


>「必要を感じない。」

それは個人の感想なので、主張としては弱くて役に立たないですね。

・メソッドを使う時に「NoWindow」であることをより明確化できる。
・間違えて「NoWindow」を指定してもnullより目立つので間違いに気づきやすい。
・名称がより明確なので、第三者がソースコードを読む時に読みやすい。
・それ専用に定義された変数に入っているので、IDEの支援を受けやすい。
・このケースだと必要性は薄いが、nullの意味が複数あるような場合でも(null,undefineなど)別々に定義できる。

くらいの利点はあるけど？
2020/03/23(月) 08:53:23.76ID:7Cqb7CJ8
NullObjectパターン使ったライブラリーとかほとんどみかけないから...
もうここまで言えば後はワカルナ?
2020/03/23(月) 09:58:46.34ID:iyDg9ARV
GetParentやGetMenuでnullチェックを忘れたらヌルポ
それを万が一忘れてもコンパイルエラーにしてくれるのがNullable
2020/03/23(月) 12:12:09.69ID:E0UAbPRX
>>871
c言語の悪癖に冒されているだけだろ。

「マジックナンバーは悪」というのは常識だろうにマジックナンバー的にnullを使う設計者の気が知れんわ。
2020/03/23(月) 13:08:13.26ID:C8qDvQHU
ここの住人って全員Androidアプリの開発者？
2020/03/23(月) 14:27:37.30ID:kwvRFU7H
Springもいるんじゃない？
小規模だけど去年bootで案件やったよ
2020/03/23(月) 23:43:05.45ID:bf1cRh+B
>>873
Keep It Simple.

NULLで現実に全く問題ないのに、NullObjectを導入することで新たな問題をむしろ入り込む余地が生まれる。
Polymorphism というが、「親Windowが無い」「Menuが無い」のような劇的な変化
は、Polymorphismでやるより、その場で if 文で場合分けするほうがプログラミングし易い。

例えば、Polymorphismに向いているのは、動物の種類を分けるようなときで、
「動物そのものが存在しない」時には向いていない。
後者は、if文無しで対処するより、本文の方でif文をちゃんと書いて場合分けした方が間違いが
生じにくくなるし、コード量も少なくなる。
だからNullObjectを使って、NullObject自身に処理を行わせて本文にはif分を使わないより、
ちゃんと本文にif文を書く方が適切なのだ。
仮にNullObjectを使っても結局、本文に if ( pMenu == &NullObject ) などという if 文を
書いてしまっては、Polymorphismにはならないし。
2020/03/23(月) 23:59:37.49ID:Kfc9ZaIq
KotlinはNullObjectよりnull推奨で
そのための前提として構文レベルで区別するための仕組みがある

x,yなのかrow,colなのか順番分からんから名前付き引数使うとか
どのオーバーロードが呼ばれるかとか

そういうのも区別出来るかどうかという似たような話になる
2020/03/24(火) 00:18:55.74ID:T0vrM+QL
>>873
NULLは、「無い」という真空状態のようなものに対応している。
(古典物理学的にはだが原則的に)真空は唯一のものであるから、
親ウィンドウがないことと、Menuがないことで、別の真空が存在する
わけではなく、唯一無二の真空で十分だとも考えられる。
それとマジックナンバーでは全く異なる、
マジックナンバーが問題なのは、後で修正しようとした時に簡単に修正できないことや、
その意味での定数を使っている場所をgrep検索で発見できないことだ。
親ウィンドウやMenuが無い事をgrep検索する必要はないし、「無い」状態を
簡単に修正する必要もない。WindowNullやMenuNullと区別した所で何か便利になる
可能性は低い。
マジックナンバーとは、
int TOMATO_PRICE = xxx;
int NUMBER_OF_TOMATO = xxx;
・・・
int TOTAL_PRICE = TOMATO_PRICE * NUMBER_OF_TOMATO + CAROT_PRICE * NUMBER_OF_CAROT;
みたいにしてから、
func(TOTAL_PRICE);
とするのと、いきなり合計価格を計算してしまった結果だけを使って
func(4032);
などとするのでは大きく分かり易さも訂正し易さも変わってくると言うことだ。
この場合、TOMATOの一個当りの値段を変えたり、個数を変えたりすることが、4032という数値では
簡単に修正できなくなってしまうのだ。
そのような問題点は、NULLにはない。
2020/03/24(火) 00:35:30.02ID:0F/GzGem
Kotlinってnullableを使っても安全だし
NullObjectも書きやすいんだよなあ
sealed classならNullObjectがこの上なく簡単に定義できて
whenで受けたときプログラマーが分岐を漏らさないようにコンパイラが教えてくれる
スマートキャストも安全で便利だ
2020/03/24(火) 00:44:02.15ID:0F/GzGem
古いものが大好きなnull爺にこの話を教えてやろう
Kotlin公式ドキュメントからリンクされてる学習者には有名なエピソードだ
nullポインタを発明したのは、クイックソート等の数々のアルゴリズムを発明し、C言語の源流にもなったALGOLを実装した天才トニー・ホーア氏
彼は近年こう回顧し謝罪している

>それは10億ドルにも相当する私の誤りだ。null参照を発明したのは1965年のことだった。
(中略)
>私は単にそれが容易だというだけで、無効な参照を含める誘惑に抵抗できなかった。これは、後に数え切れない過ち、脆弱性、システムクラッシュを引き起こし、過去40年間で10億ドル相当の苦痛と損害を引き起こしたとみられる。
2020/03/24(火) 01:42:20.76ID:T0vrM+QL
>>880
偉いとされる人が言った、または、有名な団体が作ったようなものを無条件で信じるあなたのような権威主義者が多いだけ。
有名な所が出してきたものは初期の衣の凄くもてはやされる。
使ったこともちゃんと学んだことも無いのに多くの人が褒めちぎる。
それはなぜかというと、そうすることで自分が新しいものに追いついていると
人に錯覚させることが出来ると思い込んでいるからだ。
実際には何も知らないくせに適当に新しいものを褒めているだけ。
2020/03/24(火) 01:45:43.46ID:PY48eDSf
Rustスレも荒らしてるので無視しとけ
2020/03/24(火) 03:32:39.53ID:kBVBs/yt
null自体が問題なんじゃなくて、既存の言語の型システムでnon nullableな参照型がないのが問題なだけ。ごっちゃにしすぎ。
2020/03/24(火) 03:41:54.20ID:kBVBs/yt
だから、null自体はあった方が便利、ただ、型システムの方で値型だろうが参照型だろうがnullable、non-nullableの両方定義できるようにしとけってだけ
2020/03/24(火) 07:51:18.66ID:O58srhK5
もういい加減別スレ作ってそっちでやってくれ
2020/03/24(火) 08:13:59.70ID:PfG4KY3E
>>880
その失敗の本質は、いつでもnullポインタを入れられてしまうことだよ

Nullableの元でもあるHaskellのMaybeモナドやScalaのOptionモナドは
無効を表現出来るが何ら脆弱と見られていない

KotlinのNullableは効率のため単なる参照型変数にコンパイルされるが
プログラム上は以下のようなコンテナと概念的には同じ

sealed class Nullable<T> {
open val isNull:Boolean get() = true
open val value:T get() = throw NullPointerException()
}
class Some<T>(override val value:T): Nullable<T>() {
override val isNull:Boolean get() = false
}
class None<T>: Nullable<T>()
2020/03/24(火) 08:34:24.48ID:nrIfxQG3
>>876
自分勝手な論理展開が多くて議論にならんね。

ここはkotlinスレだし、「javaではヌルポのトラブルが多い」という事実を無視した主張はクソの役にも立たない。
「ヌルポのトラブルを避けるためにはどうしたらいいか」くらい考えたら？じゃなきゃスレ違いだからNGにするわ。

そういや、>>870にヌルポの観点が抜けてるな。追加すると、
・変数の初期化ミスで変数にデフォルト値(null)が入っていても、意図しない(親無しウインドウでの)呼び出しにならない。
2020/03/24(火) 09:26:10.10ID:/F68+jPW
お前らの人生はnullみたいなもんだわ
2020/03/24(火) 12:12:39.00ID:608mB07n
ぬぬるぬるやで
2020/03/24(火) 12:12:56.90ID:608mB07n
ぬ多い
2020/03/24(火) 12:22:26.33ID:cFvopTvT
>>888
お前の人生は違うの？
2020/03/24(火) 12:48:34.07ID:Evm5n4ah
けんかはおやめABC
2020/03/24(火) 14:08:56.84ID:bSQ4VduX
いい加減レス違いですよ
2020/03/24(火) 21:20:41.36ID:PfG4KY3E
Kotlin 1.4-M1 Released
https://blog.jetbrains.com/kotlin/2020/03/kotlin-1-4-m1-released/
2020/03/25(水) 19:58:41.50ID:R+JOhqjs
初めてAndroidアプリ作成の案件に携わってるけどクソOSクソ端末に対応するコスト無駄すぎるな
イライラするわ
896デフォルトの名無しさん
垢版 |
2020/03/25(水) 20:11:20.32ID:i/r3a70w
テスト用に全ての実機用意するとかマジで有り得ん
2020/03/25(水) 22:13:46.30ID:kFDvoIpy
全ての実機ってどんだけ集めたんだ？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況