Kotlin 5

**デフォルトの名無しさん** · 2018/12/08(土) 20:29:41.41

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

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

**デフォルトの名無しさん** · 2019/05/20(月) 15:22:51.14

日経ソフトウェアは、素人向け

SoftwareDesign ぐらいか。
WEB+DB は、システム環境・プログラマーが半々ぐらい

他は、日経Linux は、ラズパイが多い

フレームワークの巨匠と言えば、掌田津耶乃・山田祥寛

山田の講習会は、数万円とか。
掌田なら、十万円ぐらい行きそうw

**デフォルトの名無しさん** · 2019/05/20(月) 16:58:22.74

つやのって読む価値のない入門書しか出してないだろ

**デフォルトの名無しさん** · 2019/05/20(月) 20:22:34.07

最近の日経ソフトウェアはPython雑誌みたいになってる
Kotlinの記事なんて全く載らない

**デフォルトの名無しさん** · 2019/05/20(月) 20:48:41.91

そういやPython大ブームだね。
機械学習関係で火が着いた感じか。

**デフォルトの名無しさん** · 2019/05/20(月) 21:27:41.17

数年後に始まる小学校でのプログラミング授業もPython採用と予想。

**デフォルトの名無しさん** · 2019/05/20(月) 21:33:58.54

授業は基本マイクラを使うぞ

**デフォルトの名無しさん** · 2019/05/20(月) 22:00:59.30

kotlinのおすすめ無料学習教材は？

**デフォルトの名無しさん** · 2019/05/20(月) 22:10:44.54

勧めるようなものは特にない

**デフォルトの名無しさん** · 2019/05/21(火) 08:28:21.83

なんか公式のチュートリアルみたいなのなかったっけ

**デフォルトの名無しさん** · 2019/05/21(火) 08:31:57.13

おすすめかどうかを意識しろ
あるかどうかではなく、おすすめかどうかだ
検索すりゃこのご時世英語含めてたくさん出てくる
そんなの見りゃわかる
おすすめできるものかどうかがいちばん大事

**デフォルトの名無しさん** · 2019/05/21(火) 10:08:36.16

ただで教える側に求めすぎだろw

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

>>723
NGに入れろ
スッキリ
▼
▲

**デフォルトの名無しさん** · 2019/05/21(火) 10:56:17.04

kotlin使った事無くて勉強中なんですが
null安全は通信で届いたオブジェクトについてどう働きますか？
あるいはデシリアライズされたオブジェクトについて
そこでもnull安全ですか？

**デフォルトの名無しさん** · 2019/05/21(火) 11:04:08.23

当然どんなオブジェクトであれKotlinで書かれている限りnull安全は機能するけど、君はそもそもnull安全を誤解してそうな予感がする

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

検索すると、null不可な変数にnullを代入できないこと、とあります。
そうすると通信で受信したオブジェクト等はどうなるのかなと。
この理解は間違っていますか？

**デフォルトの名無しさん** · 2019/05/21(火) 11:39:29.09

どこまで「使ったことない」かにもよるんだが
・nullかどうかの条件分岐をクリアした変数
・nullかどうかの条件分岐をまだやってない変数
の2つがあるだけだと思っていい

外部から取得したデータがあったとして、nullチェックをまだしていないならnullableだ
どこかで誰かが（静的文法解析上）nullではないという条件分岐を通したあとならそれはnonnull
どこかで誰かがその後にnullになるかもしれない処理を通したらnullableに戻る

**デフォルトの名無しさん** · 2019/05/21(火) 12:29:35.90

>>736
文字列とか通信データから、新たなオブジェクトを構築するのでしょ？

構築できたら、null ではないし、
データがおかしくて構築できなかったら、エラー！

**デフォルトの名無しさん** · 2019/05/21(火) 12:40:36.99

当然nonnull出ない変数ににnullをぶち込んだらエラーになる

**デフォルトの名無しさん** · 2019/05/21(火) 13:55:21.57

>>736
nullを入れられない型なのにnullを入れようとしたらその時点でオブジェクトを生成できずにエラー
なので、json文字列を受け取ってオブジェクトを生成する部分で要件に合わせて適宜いい感じに処理する必要がある

**デフォルトの名無しさん** · 2019/05/21(火) 14:53:46.84

>>736
試してみればわかると思うが、nillableな型にnull入れてObjectOutputStreamで書いた後でnullableでなくしてコンパイルしなおしてからObjectInputStreamで読もうとするとInvalidClassExceptionが出る。

**デフォルトの名無しさん** · 2019/05/21(火) 15:17:02.88

kotlin使ったことないって奴向けの説明ではないな

**デフォルトの名無しさん** · 2019/05/21(火) 16:06:22.73

図解しないとダメか？w

**デフォルトの名無しさん** · 2019/05/21(火) 17:40:26.31

そもそも聞かれてることに対する回答としてはピントがズレてる
自分の知識自慢したいイキリオタク感がすごい

**デフォルトの名無しさん** · 2019/05/21(火) 18:43:35.05

>>734がおそらくしているであろう幻想を抱いていた時期が自分にもありました
とエスパーしながらいうと、通信で受信したオブジェクト等はnullableな型を持つことになるだけで、
Kotlinにしたからといってnullチェックが要らなくなるわけではない。

>>736には誰の説明が分かりやすかっただろうか。

**デフォルトの名無しさん** · 2019/05/21(火) 20:08:28.33

>>744
ずれてないだろ。通信でオブジェクト送る話なんだから。

**デフォルトの名無しさん** · 2019/05/21(火) 20:11:45.34

Javaのコードを呼び出すところは、全部そうだね。
Kotlinはnullableであることを「強制しない」。
AndroidとかjavaxのAnnotationでもついていない限り。

**デフォルトの名無しさん** · 2019/05/21(火) 20:44:09.88

>>728
https://play.kotlinlang.org/koans/overview

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

null安全は@NotNullとどう違いますか？

**デフォルトの名無しさん** · 2019/05/21(火) 23:00:11.33

コンパイルエラーになるかぬるぽでばーんってなるかの違い

**デフォルトの名無しさん** · 2019/05/21(火) 23:15:32.28

null安全は以下の機能を包括する言葉
　・型システムでnull許容とnull不可を区別出来る
　・null許容型の取扱いを容易にするモナド操作などを言語仕様や標準ライブラリに持つ

**デフォルトの名無しさん** · 2019/05/22(水) 00:26:45.64

　 ∧＿∧　　／￣￣
　（　´∀｀）＜　　ド？
　（　　　）　＼＿＿
　│ │ │
　（＿_）___）

**デフォルトの名無しさん** · 2019/05/22(水) 13:10:44.21

iosアプリ作るのは現実的にいけそう？

**デフォルトの名無しさん** · 2019/05/22(水) 15:26:22.63

いけるいける

**デフォルトの名無しさん** · 2019/05/22(水) 17:11:00.38

大丈夫大丈夫、なんの問題もない

**デフォルトの名無しさん** · 2019/05/22(水) 19:37:38.21

逆引きのAndroid開発用のKotlin本ないの？
Javaのはあるけどさ

**デフォルトの名無しさん** · 2019/05/22(水) 21:14:49.49

>>754
>>755
ほんとのほんとに？
作り始めてまうで？

**デフォルトの名無しさん** · 2019/05/22(水) 22:18:54.87

うん、大丈夫、なにも心配することないから

**デフォルトの名無しさん** · 2019/05/23(木) 00:10:33.20

>>754,755,758
iOSアプリを実際に作った人がこの板にこんなにいるとは思えないんだがw
いや、自分もないんだけどさw

**デフォルトの名無しさん** · 2019/05/23(木) 00:56:30.37

Kotlinでの競技プログラミングのコンテストがあるよ！

5月28日の23時35分から2時間半！

Kotlin Heroes Announcement
https://codeforces.com/blog/entry/67162
https://codeforces.com/contests/1170

**デフォルトの名無しさん** · 2019/05/23(木) 01:52:40.87

英語で書かれた問題を解読するだけで2時間半が経過してしまいそうな予感

**デフォルトの名無しさん** · 2019/05/23(木) 02:45:36.97

>>760
IntがintになるかIntegerになるか考慮しないといけなかったらちょっと嫌だなあ。

**デフォルトの名無しさん** · 2019/05/23(木) 06:58:10.23

>>759
大丈夫、Kotlinも業務で使ってるしiOSアプリも業務でいくつも作ってるからさ
Kotlin nativeのiOSアプリも実際に作ってみたって人と勉強会の懇親会で話したことがある

**デフォルトの名無しさん** · 2019/05/24(金) 09:20:43.95

>>756
必要か？

**デフォルトの名無しさん** · 2019/05/24(金) 13:57:22.09

Listの初期化って

var list = listOf<Hoge>()

と

var list :Hoge? = null

どっちがいいの？

**デフォルトの名無しさん** · 2019/05/24(金) 15:11:48.77

>>765
全く違うもの出されてどちらがと聞かれても・・・

**デフォルトの名無しさん** · 2019/05/24(金) 16:53:05.84

>>765
その２つでいうなら下はリストを作れてないから上一択になるぞw

**デフォルトの名無しさん** · 2019/05/24(金) 16:57:14.79

間違えた下は

var list :List<Hoge>? = null

ね

これならどっちがいい？

**デフォルトの名無しさん** · 2019/05/24(金) 16:59:34.27

どちらにせよその2つは作られる型が違う
nullableにする必要があるかどうかで使い分けろとしか

**デフォルトの名無しさん** · 2019/05/24(金) 17:00:11.96

俺だったら何か理由がない限り上

**デフォルトの名無しさん** · 2019/05/24(金) 17:00:17.36

特別な理由がない限り上はvarじゃなくてvalにすべきじゃない？

**デフォルトの名無しさん** · 2019/05/24(金) 17:15:07.02

>>770
なぜ？

>>771
valにしたら代入できないじゃん

**デフォルトの名無しさん** · 2019/05/24(金) 17:52:50.04

val にして空の MutableList 作るのは？

**デフォルトの名無しさん** · 2019/05/24(金) 18:01:30.45

俺はemptyListだな

**デフォルトの名無しさん** · 2019/05/24(金) 18:03:21.78

？取るのめんどいから空のリストにしてくれ

**デフォルトの名無しさん** · 2019/05/24(金) 18:27:38.07

>>772
ああごめん val にしてMutableList な
だが、おまえが欲しいのはたぶん
var list = emptyList<Hoge>()

**デフォルトの名無しさん** · 2019/05/24(金) 18:51:13.35

>>772
Kotlinにおいてはvarもnullableもごく限られた場面でしか使わない例外的なものだということは知っておいた方が良い。
nullableは無駄に取り扱いが面倒だったり、varは予期せぬバグを生み出す温床になり得るから。

なので
val list = mutableListof<Unko>()

が、大抵の場面で正解。

**デフォルトの名無しさん** · 2019/05/24(金) 19:42:38.12

Unkoって何ですか

**デフォルトの名無しさん** · 2019/05/24(金) 20:03:18.59

えっお前んちUnkoねーのだっせー

**デフォルトの名無しさん** · 2019/05/24(金) 20:04:30.18

かといって盲目的に mutable collection を使うのもどうかと思うがな

**デフォルトの名無しさん** · 2019/05/24(金) 20:17:54.95

盲目的も何もコンテキストが分からないんだから一般論としてvarを使うよりはMutableListを使う方が適してると言うしかないだろ
どんな状況でも何がなんでもMutableListを使えなんて誰も言ってない

**デフォルトの名無しさん** · 2019/05/24(金) 20:23:02.45

俺も>>777にするな。

もしくはlateinitを使うか、どちらか。

**デフォルトの名無しさん** · 2019/05/25(土) 05:49:19.79

>>768
状況にもよるけど、>>782で出たlateinitか、場所によっては
val list by lazy{ [List<Hoge>を返す式] }
そもそも、listの要素が出揃っていない段階でlistを宣言するのが適切でない可能性も。
val list = [List<Hoge>を返す式]
のようにいきなり最後まで計算するか、少々面倒だけど>>773の言うように一旦
val temporaryList = mutableListOf<Hoge>()
して要素が出揃ったら
val list = temporaryList.toList()
するとか。

**デフォルトの名無しさん** · 2019/05/25(土) 06:37:38.07

lateinitはvalにできないから糞

**デフォルトの名無しさん** · 2019/05/25(土) 07:20:32.83

そんなご無体な

**デフォルトの名無しさん** · 2019/05/25(土) 08:02:42.85

valだけが正しい。valにできないなら新しいvalにコピーするべき

**768** · 2019/05/25(土) 10:50:32.51

>>783
それだとvalじゃなくてvarじゃね？

始めに空のList入れる意見が多いけど結局使う時にemptyかチェックするでしょ
nullかどうかチェックするのと同じじゃね？

**デフォルトの名無しさん** · 2019/05/25(土) 10:57:44.94

nullの警告が厳しいからこそ使うのはどうだろうか
nullならnullだと知らされるがemptyじゃ何の警告も出ない

**デフォルトの名無しさん** · 2019/05/25(土) 13:16:02.71

・リスト自体を構築するケース
　　・listを使わないケースがかなりある and 非常に効率重視(※)なら
　　　　　var list: List<Hoge>? = null
　　　　　必要になったら list = mutableListOf()
　　・そうでないなら
　　　　　val list = mutableListOf<Hoge>()

　　※mutableListOf(＝ArrayListの生成コスト)すら許容出来ない場合
　　　　なおmutableListOfと比較するとlazyの準備処理の方がコストが掛かる

・場合によって構築済みリストを入れ替える(再代入)するケース
　　var list = listOf<Hoge>()

補足： listOf()はemptyListにinline展開されEmptyListのシングルトンを返すので生成コストは無い
>>765 >>772は再代入目的のようなのでlistOfで良い

**デフォルトの名無しさん** · 2019/05/25(土) 13:19:44.44

>>787
そうとは限らない
単にリストの要素数が0ならそれでいいケースも多い
そう考えると明らかに初期化を忘れてるのが分かるという意味でnullを入れておくのもいいかもしれない

**デフォルトの名無しさん** · 2019/05/25(土) 17:48:30.03

Androidなどで、非同期処理が関わってくると、
valは注意して使わないといけない場面が、意外にたくさんあることに気が付く。

**デフォルトの名無しさん** · 2019/05/25(土) 18:20:07.77

Activityのbindingはby lazyのval
Fragmentのbindingはlateinit var

**デフォルトの名無しさん** · 2019/05/26(日) 23:17:26.29

>>765
そもそもローカル変数の話なのかプロパティの話なのか…

**デフォルトの名無しさん** · 2019/05/27(月) 12:03:53.57

emptyListってシングルトンだから生成コストがないってのは分かるんだけど、
今時その程度の生成コストを気にする場面ってそんなない気もする
富豪的プログラミングなんて言われるかもしれんけど、もはやそれ自体死語だしな

**デフォルトの名無しさん** · 2019/05/27(月) 12:57:29.86

>>793
ローカルならそもそも悩まない。

val且つmutableにして都度addallするか、var且つimmutableで丸ごと置き換えるか、はケースバイケースで。

**デフォルトの名無しさん** · 2019/05/27(月) 13:34:53.60

valで都度変数作るからなぁ

**デフォルトの名無しさん** · 2019/05/27(月) 14:33:20.72

プロパティの話ね
mutableにしてもそもそも生成は別のところでListごと作るからmutableだろうがListだろうが関係ない
当然後から代入するからvalにはできない

**デフォルトの名無しさん** · 2019/05/27(月) 14:57:26.23

copyメソッド

**デフォルトの名無しさん** · 2019/05/27(月) 23:34:59.34

サーバーサイドばっかだからかもしれんがプロパティにMutableListを使うことがそうそう無い
データクラスのコンストラクタ引数に val list: List はよくある

**デフォルトの名無しさん** · 2019/05/27(月) 23:56:54.45

内部DSLとかの指示を構築する系の実装で使うかな

**デフォルトの名無しさん** · 2019/05/28(火) 05:58:36.43

サーバーサイドかどうか関係なくない？
俺はよく使うよ。例えばツリー構造になってるデータを読み込む処理で自分の子ノードのリストを持つため、とか、これ昨日書いた。

**デフォルトの名無しさん** · 2019/05/28(火) 06:33:15.65

val text = ""

って

val text :String = ""

って書いた方がいい？

**デフォルトの名無しさん** · 2019/05/28(火) 07:05:11.16

>>802
やるメリットは特にない
むしろ本当に宣言通りStringかどうかチェックするぶんビルド遅い

**デフォルトの名無しさん** · 2019/05/28(火) 08:10:42.72

>>802
いらない。何をどう見ても明らかにStringだから意味ない。

**デフォルトの名無しさん** · 2019/05/28(火) 23:54:42.49

>>802
Javaのvarで似たような議論がある。
https://orablogs-jp.blogspot.com/2018/03/style-guidelines-for-local-variable.html

**デフォルトの名無しさん** · 2019/05/29(水) 01:39:37.10

Kotlinに、SwiftのExpressibleByStringLiteralみたいなのが無くて本当に良かったと思う
あれは呪いだ

**デフォルトの名無しさん** · 2019/05/29(水) 02:17:57.59

>>802 は、IntelljIDEA か Android Studio 使ってないのかね？
警告消して緑色になるようがんばれ
おれは警告にどうしても従えない場合でも、アノテーション使って絶対緑色にする

**デフォルトの名無しさん** · 2019/05/29(水) 04:33:25.97

Charは'a'なのね

**デフォルトの名無しさん** · 2019/05/29(水) 06:05:24.96

>>806
なにそれ？

**デフォルトの名無しさん** · 2019/05/29(水) 07:50:04.16

>>809
https://ideone.com/3YQTSZ

文字列リテラルが本当に文字列なのか分からなくなるやつ

**デフォルトの名無しさん** · 2019/05/31(金) 14:21:13.30

>>806
PHPだと1リクエストごとにFWの初期化処理を行っているのが遅い理由でしょ
特にLaravelは読み込むファイルも多いし重い

他の言語だとアプリケーションサーバ起動時に一回だけ初期化処理をするので1リクエストあたりの処理が少ない

PHPでもSwooleやReactPHPなどを使えば同じことはできるけど、まあ既存のFWを乗っけてもバグりやすいだろうね

**デフォルトの名無しさん** · 2019/05/31(金) 18:46:44.28

なんの話だよ

**デフォルトの名無しさん** · 2019/05/31(金) 22:32:24.72

やべぇやつが来たなｗｗｗ

**デフォルトの名無しさん** · 2019/06/01(土) 07:53:39.61

普通に誤爆でしょ

**デフォルトの名無しさん** · 2019/06/01(土) 11:37:30.64

android用途：元気
サーバーサイド用途：全く流行らず
kotlin/native: 瀕死
kotlin.js: 死亡

現状こんな認識なんだけど合ってる？

**デフォルトの名無しさん** · 2019/06/01(土) 11:43:16.53

Xamarin程の糞はない

**デフォルトの名無しさん** · 2019/06/01(土) 12:20:19.48

>>815
Kotlin nativeはなんかもう不死鳥とかみたく蘇ったりする予定なので書いておいてください

**デフォルトの名無しさん** · 2019/06/01(土) 14:59:33.17

身内のGraalにトドメ刺されて終わりだろ。

**デフォルトの名無しさん** · 2019/06/01(土) 15:47:15.77

/NativeがGraalにやられても/JVMがスイッチするから大丈夫

**デフォルトの名無しさん** · 2019/06/01(土) 16:20:49.17

>>815
合ってる

**デフォルトの名無しさん** · 2019/06/01(土) 16:55:01.52

nativeはまだ作成中みたいな感じなので瀕死とは違うと思うが

**デフォルトの名無しさん** · 2019/06/01(土) 17:46:40.68

Kotlinを勉強し始めたんだけどさあ
これってレファレンスを見てエディタで打ち込む->kotlincでコンパイル=>javaで動かす・・・・ってのを繰り返さないとならんの？
Swiftに言う「swift asdf.swift」みたいなのに相当するコマンドはないのかしら