Kotlin 6

**デフォルトの名無しさん** · 2019/06/22(土) 15:59:57.23

JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう

※前スレ
Kotlin 5
https://mevius.5ch.net/test/read.cgi/tech/1544268581/

**デフォルトの名無しさん** · 2019/11/21(木) 20:29:13.59

>>451
オナニーとして気持ちいいなら誰でも使うだろ。
そんなこともわからない無能かぁ……

**デフォルトの名無しさん** · 2019/11/21(木) 22:54:14.17

あるデータが有限の数値をとる場合と
値なしの特殊な状態をとる場合があるとする
その厄介さってのは多くの場合、処理の場合分けが必要ってところにある
ヒトがそういう分岐を書き忘れがちなのはご存じの通り
その結果もあって多くのプログラマはNPE恐怖症になったが、NPEを回避することが目的になっても意味がない
NullObjectの多態性やアルゴリズムの妙で分岐を潰せるならベスト
だがそうでない場合、むしろ分岐を書き忘れたとき、下手なNullObjectはフェイルファストのメリットを失うことがある

**デフォルトの名無しさん** · 2019/11/22(金) 08:14:50.32

nullセーフな言語におけるNullable型の素晴らしい点は
そのままではメソッドを呼び出すことができず
特殊値に対し場合分けの判断が必要ではないかとヒトに思い出させてくれること
不適切な!!はこれを台無しにする
不適切なNullObjectも同じで、より厄介なバグ隠蔽をもたらす

**デフォルトの名無しさん** · 2019/11/22(金) 09:18:52.84

>>454
requireNotNullやcheckNotNullも同じく台無しにする？
それともこっちは良い？

**デフォルトの名無しさん** · 2019/11/22(金) 10:51:25.32

!!のほうが2文字だし、ここでヌルポが上がるかもと分かるので好き

**デフォルトの名無しさん** · 2019/11/22(金) 11:13:57.45

念のため書いておくとKotlin標準ライブラリの関数のことね
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/check-not-null.html

**デフォルトの名無しさん** · 2019/11/22(金) 15:35:14.32

>>455
何を使うにしても状況に適したものを使えば問題ないと思うよ

**デフォルトの名無しさん** · 2019/11/24(日) 06:37:41.88

>>450
NullObjectはどのような場合でも正しく機能するNullObjectを定義できるなら優れているが、「どのような場合でも」を満たすのは難しい。
null発生の状況が複数ある場合は「どのような場合でも」というい条件を満たすNullObjectが定義可能である保証もない。
最初は条件を満たしていても、プログラムを修正していくうちに条件を満たせない場合が出てくる可能性もある。
しかも「気づかないうちに」そうなっている可能性がありたちが悪い。
条件を満たせない場所だけ分岐させるのは、NullObjectがnullチェック分岐消去を目的にしている
ことを考えると本末転倒な解決策。

**デフォルトの名無しさん** · 2019/11/24(日) 12:53:04.20

APIレスポンスとかデータ定義はNULLじゃない扱いしておいてビルドエラーもでないけど、
実際に動作させるとNULLが来てクラッシュするとかあるな

**デフォルトの名無しさん** · 2019/11/25(月) 11:44:00.50

すごーく簡略化すれば、
private hoge: Hoge? = null
public Hoge apiX() {
if (hoge == null) hoge = Hoge() //
return hoge!! // ここでnullはあり得ないよと「宣言」
}
実際にHoge()のところは、さらにJavaの他のAPI呼び出しだったりするとしても、
とにかくnullでないことさえはっきりしているならばなんでもいい。
要するにこの場合は、apiXがnullを消費する責任を持つってことだ。
持たないなら、nullableのまま返す（つまりAPIとしてはnullも正常系だと言っている）。
そんだけのことじゃないかな。

**デフォルトの名無しさん** · 2019/11/25(月) 12:58:08.39

>>459
nullobjectは「賢いnull」なんだから、null的な使い方してもいいだろ。
型安全なnullとして受け取ってnull分岐してもいいしな。

あと、null発生の状況が複数あるなら、それぞれ別のnullobjectにしていいんじゃない？。

**デフォルトの名無しさん** · 2019/11/25(月) 16:14:54.66

Javaではnullobjectを賢いnullとするのは正しいと思う

でもnull許容/非許容を型で区別出来るようになったKotlinでは
nullobjectはその利点を無くしてしまう

実装持ちobjectとnullobjectを区別する必要が無い場合は何も問題無いけど
もし「nullobjectかどうか」を判定する必要がある場合は
賢いどころか逆になると思う

**デフォルトの名無しさん** · 2019/11/25(月) 17:15:40.69

NullObjectは"Tell, Don't Ask"なクラス設計ではうまく機能するんだけど、
関数型チックになAskだらけのコードだと使い物にならんね

**デフォルトの名無しさん** · 2019/11/25(月) 17:22:39.99

＞もし「nullobjectかどうか」を判定する必要がある場合は
これはないだろ。動機そのものだから。

**デフォルトの名無しさん** · 2019/11/25(月) 18:23:52.73

>>465
それなら良いけど、ケースによらずnullの代わりに使うみたいな話の流れだったから
ログインユーザーとかも無効ユーザーオブジェクトになるのかなと

**デフォルトの名無しさん** · 2019/11/25(月) 18:24:22.70

nullの場合の動作を
呼び出す側が決めるのか呼び出される側が決めるのか
どちらが適切なのかを考えるといい

呼び出される側が100%決め打ちできるユースケースならNullObjectは有効
呼び出し側でハンドリングしたくなったら邪魔

**デフォルトの名無しさん** · 2019/11/25(月) 18:27:30.40

java脳からkotlin脳へアプデが必要だけど
私の脳はnull

**デフォルトの名無しさん** · 2019/11/25(月) 18:49:15.70

Null Objectは単なる先送りで、ある意味!!が目指す方向とは真逆。
エラーが起きないから落ちることはないだろうけど、
使う側はエラーなのか無視されているのかわかりにくくなる。

**デフォルトの名無しさん** · 2019/11/25(月) 19:00:53.76

>>468
>呼び出し側でハンドリングしたくなったら邪魔

型無しのnull使うよりマシだろ。
許容するととんでもないところから紛れ込むnullの方がよっぽど邪魔。

**デフォルトの名無しさん** · 2019/11/25(月) 19:04:09.34

>>470
Nullableって知ってる？

**デフォルトの名無しさん** · 2019/11/26(火) 08:06:30.50

>>471
nullableでnon-nullにできたっけ？

**デフォルトの名無しさん** · 2019/11/26(火) 09:17:18.40

>>472
nullが正常系である場所ではnullabeを使い、nullが紛れ込んだらバグになる場所では非nullを使うって話がもう出てる
適切にゾーニングできているなら紛れ込むことをそう恐れる必要がない
nullという特殊値に対して意識が必要な場所はnullabeという型で言語仕様レベルで明確化でき区別できるからメリットがあり、型無しのnullというほど不便なものでもない

**デフォルトの名無しさん** · 2019/11/26(火) 09:21:30.92

>>465
それがないならNullObjectがいいと思うよ
そこを否定している人はいないはず
ただ多くの人は経験上避けがたいと思ってるから意見が合わないんだろうね
解放閉鎖原則と単一責任原則とで作ってくと最初の動機だけではなかなか完結しない
全部ビジターパターンでとことんNullObject-ableな型にお伺いをたてるように作れば完璧にできるだろうけど、そこまで作り込むコストを考えたら適材適所でnullableを使い分けるのが現実解ってのが落としどころだと思う
Kotlinが選び提供している価値はnullセーフであってnullフリーではないし

**デフォルトの名無しさん** · 2019/11/26(火) 10:05:06.19

NullObjectって非同期呼び出しとかどうすんの
OOの原理主義的にはコールバックの呼び出しもしないのが正しいんだろうけど、
最近は前後で文脈が繋がってて、コールバックが呼ばれないままだとまともに動かないケースがほとんどだよね
かといってコールバックしようにも引数に何渡せばいいのかとか色々無理がある

**デフォルトの名無しさん** · 2019/11/27(水) 12:20:06.50

>>473
nullを使っても問題は限定的だと思うけど、あえてnullを使うメリットはあるのかしらん？
実装上の手間が省ける、くらいしかないと思うけど。

**デフォルトの名無しさん** · 2019/11/27(水) 12:55:51.34

>>476
>>438,453-454あたりを見てくれ

**デフォルトの名無しさん** · 2019/12/06(金) 11:58:04.47

なぜKotlin/Nativeのメモリモデルが成り立たないか
https://itnext.io/why-the-kotlin-native-memory-model-cannot-hold-ae1631d80cf6

**デフォルトの名無しさん** · 2019/12/06(金) 14:42:47.13

三行に要約すると？

**デフォルトの名無しさん** · 2019/12/06(金) 15:14:59.67

>>479
freezeによる制限とAPIはKotlin/Nativeのみ
そのせいでマルチプラットフォーム機能がお通夜状態
だから考え直せ

**デフォルトの名無しさん** · 2019/12/06(金) 16:40:22.09

> This is the work of “top-level objects are frozen by default” and “a frozen datum cannot be mutated”.
Kotlin native試したことないけどこれ糞過ぎやろ
既存の(JVM向けに書かれた)コードがほぼ例外なく実行時にクラッシュすることになるやんけ
こんな互換性の欠片もないもん作るんやったらもう別言語でええやろ

**デフォルトの名無しさん** · 2019/12/06(金) 22:26:57.61

kotlinてクラス変数に型推論使えるの？
Javaで無名クラスに利用できたらいいのにと思ったことがある

class Hello {
public var xyz = new Object (){　int x; int y; int z;　};
void setX(int value){ xyz.x = value; }
}

**デフォルトの名無しさん** · 2019/12/06(金) 23:00:45.17

>>482
private varでもいいなら使える
https://paiza.io/projects/qjWZT-Uy91UelIcTFqoKIA

**デフォルトの名無しさん** · 2019/12/09(月) 00:07:21.07

>>483
できるのか！　これができるとリフレクションを使ったフレームワークに幅が広がりそうだよねえ
特定の変数名をもつオブジェクトに値を代入するとかさ

**デフォルトの名無しさん** · 2019/12/11(水) 10:04:40.40

Kotlin 1.4以降に何を期待するか
https://blog.jetbrains.com/kotlin/2019/12/what-to-expect-in-kotlin-1-4-and-beyond/

品質とパフォーマンスに焦点を当て
大きな機能追加よりエクスペリエンスを向上させること（小さな機能追加はある）

Trailing Commaはありがたい

**デフォルトの名無しさん** · 2019/12/11(水) 10:35:44.03

GitHub統計
https://madnight.github.io/githut/

中々上がらない原因になってそうなのは
・スマホアプリでのクロスプラットフォーム性が他より劣る
・Kotlin/NativeやGraalVMのAOTの性能が
　他のGC持ちAOT(Go, C#)に全然追いつけてない
・AltJSとしてはTSに完敗
・Javaが割とモダン化していってる

**デフォルトの名無しさん** · 2019/12/11(水) 17:32:54.10

kotlin/jsは可能性がなさすぎるから諦めて他のとこにリソース使ってほしい。。

**デフォルトの名無しさん** · 2019/12/11(水) 18:11:35.13

ちょっとオワコン感が漂い始めたよね

**デフォルトの名無しさん** · 2019/12/11(水) 18:44:39.88

これから始めようと思ってた

**デフォルトの名無しさん** · 2019/12/11(水) 21:20:44.17

クロスプラットフォームは糞に例外なし

**デフォルトの名無しさん** · 2019/12/12(木) 03:31:17.93

nativeでクロスプラットフォーム狙うならリッチな標準クラスライブラリがないと駄目だろ。言語だけ用意されても。
kotlin/JVMみたく他に寄生するなら寄生先のライブラリ使えるからいいけど。

nativeどうする気なの。

.netやjavaみたいな最低限の標準クラスライブラリないと役立たず。

**デフォルトの名無しさん** · 2019/12/12(木) 10:07:02.43

どうする気もないでしょ
JBが本気でKotlinで天下獲るつもりならGoLandとRiderとResharperを今すぐ廃止すればいい
それをしていないということはその程度の覚悟なんだよ
粛々とチームを解散して開発者を解雇するだけだ

**デフォルトの名無しさん** · 2019/12/13(金) 23:58:30.55

クロスプラットフォームがこんなに早く普及し始めるとはのぉ。

**デフォルトの名無しさん** · 2019/12/14(土) 00:19:00.68

ＪａｖａでWindowsで開発してlinuxでうごかしとる
バージョンはこないだまで６だった
やっとＪａｖａのかかとの所ぐらいまで世界が追い付いてきたようだ

**デフォルトの名無しさん** · 2019/12/17(火) 06:30:13.16

Kotlin/Nativeってバージョン番号が1.0を越えてるけど、
ベータ版を脱したってことでいいの?

**デフォルトの名無しさん** · 2019/12/17(火) 10:45:01.35

クラスのnullableなインスタンスプロパティが複数(a,b,c)あって、
それらが全部nullじゃないときに実行できるメソッドあり、
fun execute() {
　if (!canExecute)
　　return
　val a_ = a!!
　val b_ = b!!
　val c_ = c!!

}
いちいちこういう事やってんだけど、なんとかならんもんか・・

**デフォルトの名無しさん** · 2019/12/17(火) 11:51:21.83

小手先のテクニックよりも設計を見直すべきでは
a, b, cを一つの型に纏められないの？

**デフォルトの名無しさん** · 2019/12/17(火) 18:50:15.12

MVVMのViewModelつくったことないの?
ViewModelを作るとたいがいこんなことになるんだが。

**デフォルトの名無しさん** · 2019/12/17(火) 19:23:57.27

>>498
いや、なんでa, b, cをわざわざ別個の変数に代入し直す必要があるの？
そこMVVM云々の事情は無関係だよね
HogeModel(a!!, b!!, c!!).execute()とかなら別に違和感ないやろ

**デフォルトの名無しさん** · 2019/12/17(火) 19:27:54.98

普通のクラスだとこんなことにならんが、複雑に状態が遷移するViewModelだとこんなことになる。

ちょっと前にNullオブジェクトパターンの話題あったけど、NullオブジェクトじゃなくてViewModelの内部でStateパターン使えばたぶんいけると思うがめんどくさそう。

**デフォルトの名無しさん** · 2019/12/17(火) 19:32:07.34

>>499
ああ、!!排除するために内部でそのために別のクラスに追い出せってことかなるほど。

**デフォルトの名無しさん** · 2019/12/17(火) 20:00:31.90

つか、そのためだけならクラスを別に用意するんじゃなくてもいいんだよな。
ただ、executeCoreって別のnon-nullableな引数とるメソッド用意してexecuteCore(a!!,b!!,c!!)するだけで

実際のその先の処理もa_.hoge(b_,c_)とかでちゃんと処理委譲してるから毎回10数行レベルで、更に他に分割するって発想なかったわ。

**デフォルトの名無しさん** · 2019/12/17(火) 21:26:42.16

!! はいかんぞ

**デフォルトの名無しさん** · 2019/12/17(火) 21:41:44.72

みんないろいろなやり方で頑張ってるみたい
https://discuss.kotlinlang.org/t/kotlin-null-check-for-multiple-nullable-vars/1946
https://stackoverflow.com/questions/35513636/

**デフォルトの名無しさん** · 2019/12/18(水) 01:11:24.71

nullチェックのガード節後に、スマートキャストが効けばいいわけだな

**デフォルトの名無しさん** · 2019/12/18(水) 02:07:44.40

あたたたたたたた!!

**デフォルトの名無しさん** · 2019/12/19(木) 00:36:56.60

あたたたたたたた?.let {
}

**デフォルトの名無しさん** · 2019/12/19(木) 08:27:47.53

みなさん
今日からKotlinを目指す事になった者です
よろしくお願いします

**デフォルトの名無しさん** · 2019/12/19(木) 08:45:53.31

kotlinを目指す
java始めたってことか？

**デフォルトの名無しさん** · 2019/12/19(木) 08:55:17.26

>>509
え？
Kotlinって言語の事じゃなかったんですか！？
てっきり言語かと

**デフォルトの名無しさん** · 2019/12/19(木) 08:56:43.83

やっぱりプログラミング言語で合ってるじゃないですか
初心者をいじめないで下さいよ

**デフォルトの名無しさん** · 2019/12/19(木) 08:57:14.39

ID:xYioGlNJをNGにした

**デフォルトの名無しさん** · 2019/12/19(木) 09:10:42.29

kotlin始めましたならわかる
kotlin目指したらhallo world書いたら目標到達じゃないか

**デフォルトの名無しさん** · 2019/12/19(木) 09:11:54.91

>>513
Kotlin始めました

**デフォルトの名無しさん** · 2019/12/19(木) 09:14:19.85

>>513
でもまだ本が届いてないんです！
かといってプロゲートを調べたらKotlinがないしドットインストールを調べたらクッソ高ぇし
ヨ■■■で
作って楽しむプログラミング Androidアプリ超入門―Android Studio3.3 & Kotlin1.3で学ぶはじめてのスマホアプリ作成
って本をポチりました

**デフォルトの名無しさん** · 2019/12/19(木) 09:15:16.14

>>513
こんな状態で僕はKotlinを始めている事になるのでしょうか！？

**デフォルトの名無しさん** · 2019/12/19(木) 11:32:38.18

思い込みが大事

**デフォルトの名無しさん** · 2019/12/19(木) 12:36:14.53

>>516
なってるよ
だからもう書き込まないでね

**デフォルトの名無しさん** · 2019/12/19(木) 12:51:05.10

>>514
そんなこと書いた張り紙がラーメン屋にさりげなく貼られてたらどうしよう

**デフォルトの名無しさん** · 2019/12/19(木) 13:37:11.92

>>509
すいませんでした
調べたらKotlinの源がJavaという事が判明しました
NGIDを解除しました
ですから今はまずプロゲートでJavaをやってます

**デフォルトの名無しさん** · 2019/12/19(木) 13:41:10.68

オンライン講座やアプリにカネをかけたら負けだと思っているのでJavaの本もポチりました
「Java1年生―体験してわかる!会話でまなべる!プログラミングのしくみ」
まずはこれを読んでから
「作って楽しむプログラミング Androidアプリ超入門―Android Studio3.3 & Kotlin1.3で学ぶはじめてのスマホアプリ作成」
を読む事にしました

アデュー

**デフォルトの名無しさん** · 2019/12/19(木) 13:48:14.38

逆やろ
本買ったら負け
ほぼオンラインで事足りる

**デフォルトの名無しさん** · 2019/12/19(木) 13:58:35.22

>>522
俺たちは理解力ゼロの人間だから

**デフォルトの名無しさん** · 2019/12/19(木) 14:25:11.21

各言語のスッキリシリーズを生み出した、伝説の本！
まずこの本で、オブジェクト指向を学ぶ。
スッキリわかる Java入門第2版、2014

その後に、太郎本をやるのが定番！
Kotlinスタートブック -新しいAndroidプログラミング、長澤太郎、2016

**デフォルトの名無しさん** · 2019/12/19(木) 15:34:22.45

>>515
たぶん開発環境があってないから楽しめないと思う
サンプル系の本は苦しみながら修正して作るものだと覚悟して望んでください
そうすればとてもいい本です

**デフォルトの名無しさん** · 2019/12/19(木) 16:26:30.93

>>522
そういや動画はわかりやすいと誰かが書いてたな。俺はわざわざ動画探して見ないけど。

**デフォルトの名無しさん** · 2019/12/19(木) 19:30:40.54

手動かしてたら覚える
本も動画もメンターもいらなかった

**デフォルトの名無しさん** · 2019/12/19(木) 21:42:53.35

勉強してプログラミングを覚えてからアプリを作るっていう考えがそもそも間違い
まず作りたいものがあるべきでその作りたいものを作るために必要な知識を
都度調べて問題の解決を繰り返すという方法で進むべき
作りたいものがないなら向いてないからプログラミングなんかやめてしまえ時間の無駄

**デフォルトの名無しさん** · 2019/12/19(木) 22:02:46.62

まあ、そう言わんでも
君が数学を学んでいた頃、数学でやりたかったことあったの？

**デフォルトの名無しさん** · 2019/12/19(木) 22:20:55.18

回転機能とワイヤーフレーム３Ｄでドヤってたら
あっという間に世間はポリゴンだのテクスチャだのバンプマッピングだの

ほんの数年の間の話

**デフォルトの名無しさん** · 2019/12/19(木) 22:23:45.85

大体アプリを作るのに必要な知識って言語の文法だけじゃない
Android SDKの知識も必要だし設計もMVVMとかfluxとかいろいろある
今の主流の外部ライブラリが何かとか非同期処理の実装はどうするか
Firebaseとかも活用した方がいいだろう
必要な知識が広すぎるのに目的もなくただ漠然と必要そうだとつまみ食いしてるだけで
あっという間に時間は終わっていく
大体5年もすればソフトウェアの世界は一変する
結局何も生み出せないまま技術に振り回されて時間が過ぎていくだけ

**デフォルトの名無しさん** · 2019/12/19(木) 23:03:29.10

ふーん、偉いんだね

**デフォルトの名無しさん** · 2019/12/19(木) 23:26:51.07

さっき気がついたんだけど
kotlinってimportしなくなった？不要なの？
Math.sin/cos/tan使ってもimportせずに使えてなんか変な感じです

**デフォルトの名無しさん** · 2019/12/20(金) 06:46:42.42

>>533
https://kotlinlang.org/docs/reference/packages.html#default-imports

Javaでも java.lang.* (StringやMathなど) はインポート書かずに使える

**デフォルトの名無しさん** · 2019/12/20(金) 10:39:15.14

1.4でkotlin/nativeが爆速になってgoが死亡する世界線に行きたい

**デフォルトの名無しさん** · 2019/12/20(金) 19:57:21.77

誰かが１０００億円の間違いしなかった世界がいい
今更Kotlinとか付け焼刃

**デフォルトの名無しさん** · 2019/12/20(金) 21:49:59.43

>>528
その通り。

まあしかしそれ言ったら学校教育は完全にダメだね。

**デフォルトの名無しさん** · 2019/12/21(土) 15:23:12.50

>>536
何の話？

**デフォルトの名無しさん** · 2019/12/21(土) 15:26:06.69

>>533
俺は変な感じがしない。なぜならJavaの頃からそのように使っているからだ。というかむしろそうでない方に違和感がある。

**デフォルトの名無しさん** · 2019/12/22(日) 00:16:19.54

>>538
本人ではないが>>536はJavaに最初からnulll(=１０００億円の間違い)がなかった世界線に行きたいらしい。

**デフォルトの名無しさん** · 2019/12/22(日) 01:17:50.71

Union typeないの？

**デフォルトの名無しさん** · 2019/12/22(日) 02:55:53.04

union って、C言語の union のこと? そういうのはないね。自分で無理矢理 Byte 配列に詰め込むのなら出来るが。

**デフォルトの名無しさん** · 2019/12/22(日) 03:55:07.63

>>541
sealed class

**デフォルトの名無しさん** · 2019/12/22(日) 07:09:03.62

こういうやつでしょ
　var a : (String | List<Int>) = "aaa"
　a = listOf(10)
無いよ

**デフォルトの名無しさん** · 2019/12/22(日) 17:46:16.29

sealed class Either<L, R>{
class Left<L, R>(val value: L): Either<L, R>()
class Right<L, R>(val value: R): Either<L, R>()
}

var a: Either<String, List<Int>> = Either.Left(“foo”)

https://pl.kotl.in/1oWpsAGCs

KotlinはJavaの足枷が重いから劇的に使いやすくなることはなさそう

**デフォルトの名無しさん** · 2019/12/22(日) 22:24:55.21

Union typeをサポートするとString?型もString | nullの略記でしかなくなるのだろうか

**デフォルトの名無しさん** · 2019/12/23(月) 13:25:26.95

しかしnullは型の名前ではないな。

**デフォルトの名無しさん** · 2019/12/23(月) 21:19:46.42

Unitと同じくオブジェクト宣言にすれば型としても値としても使える

TypeScriptのようにリテラル型という方式もあるけど
function f(): string | null | 10 { return 10; }

**デフォルトの名無しさん** · 2019/12/23(月) 22:41:55.78

sealed classってinterfaceを持たないfinalなクラスをEither型には出来ないってことであってる?

**デフォルトの名無しさん** · 2019/12/23(月) 22:55:01.39

GraphQL使ってるとunion欲しくなるよな

**デフォルトの名無しさん** · 2020/01/01(水) 00:07:09.43

あけましておめでとうございます。
ことりんもよろしくおねがいします。