Kotlin 4

**デフォルトの名無しさん** · 2018/07/17(火) 18:00:27.88

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

※前スレ
http://mevius.5ch.net/test/read.cgi/tech/1521401186/

**デフォルトの名無しさん** · 2018/07/19(木) 22:51:52.90

>>26
テスト書かなきゃだめなんですね

>>27
そうしてるんですがNo main class specified 言われるんですよ

main classってなんや
static void main …のあのおまじないですか？

**デフォルトの名無しさん** · 2018/07/19(木) 22:57:46.33

>>28
main関数の書いてあるエディタのタブ部分を右クリックでメニューからのRunはどう？

**デフォルトの名無しさん** · 2018/07/20(金) 01:12:02.79

fun main(args: Array<String>) { } をクラスの外に作った瞬間にその行の左に緑の三角が表示されて、そこから実行できるね
クラスの定義は無くてもいいけど、クラスの中じゃダメだ

**デフォルトの名無しさん** · 2018/07/20(金) 06:18:13.10

>>27のやり方で普通に動いたよ。
左側のProjectペインから、その実行したいktファイルを右クリックして、そこからRunしてもだめ？
もしくは上の方にあるRun configurationを一回削除してから同じことをしてみるとか。

**デフォルトの名無しさん** · 2018/07/20(金) 06:24:04.39

>>27
一応確認だけど、関数名はmainになってるよね？
他の名前だとだめだよ

**デフォルトの名無しさん** · 2018/07/20(金) 09:18:38.44

>>25
状況がよくわからないからそのエラーが出た時のスクリーンショット取って見せて。ソースが表示されてる状態のな。

**デフォルトの名無しさん** · 2018/07/20(金) 09:31:09.84

Kotlinスレの半分は優しさで出来ています

**デフォルトの名無しさん** · 2018/07/20(金) 12:27:14.89

残りの半分はXamarinで出来ています

**デフォルトの名無しさん** · 2018/07/20(金) 12:34:08.35

それだけはお許しください

**デフォルトの名無しさん** · 2018/07/20(金) 18:21:03.22

Delphiがアップを始めました

28 · 2018/07/20(金) 22:04:55.35

みなさん回答ありがとうございました

新しいプロジェクトでやったらできました。
おそらく原因はNewでファイルを作るときにkotlin scriptを選んでしまったためだと思われます

srcディレクトリ直下にkotlin file/class
でファイルを作ったら実行できました。

**デフォルトの名無しさん** · 2018/07/20(金) 22:56:26.76

Xamarinみたいな糞でやるからそうなる

**デフォルトの名無しさん** · 2018/07/21(土) 00:11:05.11

https://gigazine.net/news/20180720-android-to-fuchsia-in-5-year/
kotlin短い命だったな

**デフォルトの名無しさん** · 2018/07/21(土) 00:19:38.66

あ、そこまで頭回らんかった
kotlin 作ったやつが一番辛い案件だな

**デフォルトの名無しさん** · 2018/07/21(土) 00:56:25.52

今更、LinuxベースじゃないOS作ったから使えよ！って言われて流行ると思う？

**デフォルトの名無しさん** · 2018/07/21(土) 02:48:12.63

Kotlin は今はとにかく JavaVM で動くコードを出すコンパイラで Android 開発で使って貰って
世界中に広めてある程度定着させれば良い。その隙にネイティブとか新OSの実行環境用コードを
出すコンパイラを作ってくれれば問題なし。そして Java は死亡して Kotlin は生き残る。

**デフォルトの名無しさん** · 2018/07/21(土) 03:41:06.56

JavaVMなどの他の環境の寄生をやめるなら基本的なクラスライブラリはどうするんだ?
コンパイラだけじゃダメじゃね。javaみたいなコレクションフレームワークやらHttpやソケットライブラリあたりも標準で用意してくれないとね。というか寄生やめるならUIフレームワークも必要じゃねぇ?無理だな。
サーバーサイドならいらんが。

**デフォルトの名無しさん** · 2018/07/21(土) 04:12:26.67

ごめん。寄生やめるって話じゃなくて今はとりあえずandroidに寄生してその間に広めてその後は他の寄生先見つけりゃいいって話しかな?

**デフォルトの名無しさん** · 2018/07/21(土) 05:31:45.74

寄生しても良いし、根底から全部作っても良いが、とにかく生き延びる率は非常に高いと思う。

まあでもネイティブでライブラリ全部作るとしてもそんなに時間掛からないんじゃないかな。
問題はどういうやつを作るかだと思う。

**デフォルトの名無しさん** · 2018/07/21(土) 07:39:28.20

Kotlin良い言語だからもったいないよな
というか新OSに入れ替わるとしても、既存のAndroidアプリ資産を無視するわけがないから何かしらの互換は保たれると思うけど

**デフォルトの名無しさん** · 2018/07/21(土) 10:59:13.01

JavaFXをKotlinで拾ってくれないかな？
OpenJDK+OpenJFX+Kotlinでまとまってくれれば
みんな幸せ

**デフォルトの名無しさん** · 2018/07/21(土) 11:41:25.99

>>40
対応言語にKotlinじゃなくてSwiftが入っているというのが、危機感を刺激される。
>>48
ぜひそうなって欲しい。

**デフォルトの名無しさん** · 2018/07/21(土) 16:00:14.10

なにこれ、最近kotlin始めたばかりなのに終了かよwwww

**デフォルトの名無しさん** · 2018/07/21(土) 16:53:29.87

Fuchsiaが普及するとしてもその頃にはKotlin/Nativeも出来上がってるでしょ
ただ、Googleの進め方を見るにKotlin/Dartの実装も検討した方がいい気はする

**デフォルトの名無しさん** · 2018/07/21(土) 16:55:38.31

Dart程の糞はない

**デフォルトの名無しさん** · 2018/07/21(土) 17:08:37.75

まぁ、でもnull safetyを存分に味わうにはkotlinが標準クラスライブラリを用意してくれるのがいいんだけどね。

**デフォルトの名無しさん** · 2018/07/21(土) 20:32:33.33

結局javaのライブラリに依存しちゃうもんねえ

**デフォルトの名無しさん** · 2018/07/22(日) 00:48:56.80

その点、オラクルってメシウマだよな

**デフォルトの名無しさん** · 2018/07/22(日) 01:05:02.82

>>53
これあくしろよ
ファイル周りぐらいでもやってくれ～

**デフォルトの名無しさん** · 2018/07/22(日) 06:57:39.00

>>51
現状でも、言語仕様を一つ修正するのにJVM, JS, Nativeの3通りの変更が必要になる。
この上、Dartのサポートとか、なんという無茶振り。

**デフォルトの名無しさん** · 2018/07/22(日) 08:47:40.36

>>53
せめてnull safety対応generics欲しいよね。

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

JSはいっそ無くしても良いと思うけどねえ

**デフォルトの名無しさん** · 2018/07/22(日) 22:33:54.14

ことりんjsにトランスできたんか…

**デフォルトの名無しさん** · 2018/07/23(月) 02:10:39.62

できるそうだがやったことがない・・・やればいいんだなw

**デフォルトの名無しさん** · 2018/07/23(月) 06:25:10.31

遊びで触ったことあるけど、メリットを何も感じなかった。
特に他のJSライブラリを使うのがえらく面倒くさい。

**デフォルトの名無しさん** · 2018/07/23(月) 07:32:27.66

サーバーサイドでKotlin使ってたら有用な面もある
計算やチェック処理なんかをクライアント側と共用出来るから

**デフォルトの名無しさん** · 2018/07/23(月) 09:37:43.10

JSいらんから、その分の労力をNativeに注力してくれ

**デフォルトの名無しさん** · 2018/07/23(月) 10:28:50.79

>>40
＞C言語、C++、Dart、Go、Python、Rust、シェルスクリプト、Swift、TypeScript

この中で生産性の良く主流になりそうな言語ってどれだろう？
PythonかSwiftくらい？

**デフォルトの名無しさん** · 2018/07/23(月) 12:13:07.35

>>65
あとTypescriptかなあ。
Goはキモいからそこまで広がらないと思う。

**デフォルトの名無しさん** · 2018/07/23(月) 12:16:53.60

それ最後に書いてあるよ。

暑さには要注意だ。脳が暖まり過ぎると段々おかしくなる。

**デフォルトの名無しさん** · 2018/07/23(月) 22:50:39.12

>>66
キモナイ

**デフォルトの名無しさん** · 2018/07/23(月) 23:41:47.31

入れたときの型そのままで取り出せる汎用的なmap的なもんって実装できないかな

**デフォルトの名無しさん** · 2018/07/24(火) 00:08:17.47

Keyの型にValueの型を持たせればできそう

**デフォルトの名無しさん** · 2018/07/24(火) 00:25:53.51

>>69
Anyとスマートキャスト利用するしかないだろうなあ

**デフォルトの名無しさん** · 2018/07/24(火) 02:12:36.15

>>66
TypescriptってC#scriptみたいな物か
何気に一番Javaに近そうねｗ

**デフォルトの名無しさん** · 2018/07/24(火) 06:13:07.75

>>72
確かにJavaに似てるけど、あれは普通のJSの拡張みたいなもんだから使いやすい、というか既にめっちゃ使われてる

**デフォルトの名無しさん** · 2018/07/24(火) 06:36:17.05

>>73
KotlinよりTypescriptの方が流行る?

**デフォルトの名無しさん** · 2018/07/24(火) 06:45:51.05

用途が違いすぎるから比較できない。

**デフォルトの名無しさん** · 2018/07/24(火) 07:40:56.91

TSからJS呼ぶときに戻り値の型意識しなきゃいけないことにイラつく感覚がKotlinからJava呼ぶときにnull意識しなきゃいけないときにイラつく感覚と似ている

**デフォルトの名無しさん** · 2018/07/24(火) 07:44:57.16

めっちゃ分かる

**デフォルトの名無しさん** · 2018/07/24(火) 09:54:20.04

てか、CとTypescriptとその他を比較する意味あんのか？
分野が違いすぎんだろ

**デフォルトの名無しさん** · 2018/07/24(火) 10:58:03.97

null安全特有のバグが入ったり
null安全のためにコードが長くなったりで
あんまメリットない気がしてきた

**デフォルトの名無しさん** · 2018/07/24(火) 11:05:46.42

Javaが有償化するけど、Kotlinにも影響ある？

**デフォルトの名無しさん** · 2018/07/24(火) 11:08:31.26

なんで影響がないと思ったのか

**デフォルトの名無しさん** · 2018/07/24(火) 11:47:22.80

いやひょっとしたら、JetBrainsがいい感じでやってくれるかと．．．

**デフォルトの名無しさん** · 2018/07/24(火) 11:56:29.41

>>69だけどkotlinだと無理っぽいな
arrow-ktでlistっぽいのならあったけど
scalaだとshapelessってライブラリで実現してるらしい

**デフォルトの名無しさん** · 2018/07/24(火) 12:01:17.61

>>80
Oracle版JDKの有償化な
そのためにOracle自身もOpenJDKに力入れてきたんだから特に問題ない(KotlinもJavaも)

**デフォルトの名無しさん** · 2018/07/24(火) 12:13:14.69

>>83
最近ちょこちょこ聞くようになった依存型がこれに使えるのね

**デフォルトの名無しさん** · 2018/07/24(火) 12:15:58.38

>>79
null安全が好きでないなら、動的型付言語を使ったほうが幸せになれるんじゃない？

**デフォルトの名無しさん** · 2018/07/24(火) 12:37:31.12

>>69 >>83
どういうの使用イメージを望んでるのかよく分からないので
コンパイル不可で構わないから使う側の疑似コードを書いてみてほしい

**デフォルトの名無しさん** · 2018/07/24(火) 12:37:44.64

JetBrainsJDKは理想だけど、さすがにそんなことやるほど体力のある会社じゃないだろ

**デフォルトの名無しさん** · 2018/07/24(火) 12:38:02.51

>>79
煽るわけじゃなく、純粋に知りたいのだけど、null安全特有のバグって、どんなのがあるの？

**デフォルトの名無しさん** · 2018/07/24(火) 12:47:46.02

null安全のために記述が長くなるってのもよく分からんな
kotlinはそうならないようにかなり配慮されてると思うのだけど、もしかしていちいち全部ifでnullチェックでもしてるんじゃないの

**デフォルトの名無しさん** · 2018/07/24(火) 13:09:50.01

>>88
そうするとGoogleのAndroidのような面倒な問題を抱える可能性があるのでは？
素直に OpenJDK 使っといた方が良いと思うのだが。

**デフォルトの名無しさん** · 2018/07/24(火) 13:19:48.44

LTSしてくれるならね

**デフォルトの名無しさん** · 2018/07/24(火) 18:26:44.44

RedHatがOpenJDK11を独自にLTSするらしいから、RedHat系のディストリビューション使ってるなら大丈夫だろ
ubuntuは知らん

**デフォルトの名無しさん** · 2018/07/24(火) 18:37:37.15

null安全のせいでコードが長くなるのは

・nullを返しうるメソッドだけど今回に限っては絶対にnullじゃない

ってケースで !! の2文字が増えるぐらいでは

**デフォルトの名無しさん** · 2018/07/24(火) 18:40:45.65

>>93
つまりWindowsは死亡と。

**デフォルトの名無しさん** · 2018/07/24(火) 18:47:44.94

>>95
これを機にWndowsServerなんてカスは滅ぼそう

**デフォルトの名無しさん** · 2018/07/24(火) 18:51:34.06

AdoptOpenJDKが無償のLTS提供するよ

**デフォルトの名無しさん** · 2018/07/24(火) 19:06:30.65

>>97
GitHub見てこいよ
アレをプロダクトで安定して使えるようになるまでまだまだ先は長そうだぞ

**デフォルトの名無しさん** · 2018/07/24(火) 19:30:50.32

>>87
val map = HashMap<String, 抽象的な何か>()
map["hoge"] = "文字列"
map["fuga"] = 100

val str = map["hoge"] // :String
val num = map["fuga"] // :Int

みたいな感じで
とにかく型チェックやらキャストやらが面倒くさい
実際には自作クラスとかも突っ込みたい

**デフォルトの名無しさん** · 2018/07/24(火) 19:54:27.68

試してないんで適当言うけど
Class.forName(className).kotlin.cast(value)
とかでなんとかならんの

**デフォルトの名無しさん** · 2018/07/24(火) 20:39:35.62

>>99
型チェックなしだと取り出した変数が何型になっているかわからなくて結局扱えないのでは？

**デフォルトの名無しさん** · 2018/07/24(火) 20:48:13.92

その後処理分ける時点で型は見ることになりそう

**デフォルトの名無しさん** · 2018/07/24(火) 21:04:13.34

すまん伝わりやすいかと思って抽象的な何かって書いたけど語弊があるわ
まず抽象クラスやらスーパークラスやらこの時点で指定してたらダメだしな
ちなみにarrow-ktのHListはタプルみたいな感じになってた

**デフォルトの名無しさん** · 2018/07/24(火) 21:09:27.91

マップに値を突っ込む人は中身の詳細を知らなくて、値を取り出す人はどのキーに何が格納されているか知っているようなシチュエーション、例えば設定ファイルのローダーみたいな奴への適用ならわからんでもない。

**デフォルトの名無しさん** · 2018/07/24(火) 21:17:20.64

何に使う気かっていうとJSFでFlushっていう画面間で値渡すためのMapがあるんだけど、型チェック面倒くさいしチェックしないのも嫌だしでいっそ別に用意できないかと思った
入れるときも取り出すときも型は分かってる状況だな

**デフォルトの名無しさん** · 2018/07/24(火) 21:30:43.77

XMLなりで文字列化しといて使うときにデシリアライズすれば？

**デフォルトの名無しさん** · 2018/07/24(火) 21:57:49.15

keyごとに型が決まってるならjson文字列にしておいてGson使って取り出すとか

**デフォルトの名無しさん** · 2018/07/24(火) 22:34:12.22

>>99
Mapに代入のみで型認識するのは難しいな

タプル的な感じでやるか
https://ideone.com/Aekjqn

事前定義でMapに関連付けるか
https://ideone.com/rCFcai

むしろ変数に型が無い言語使うか
https://ideone.com/BUHFe3

**デフォルトの名無しさん** · 2018/07/24(火) 23:50:03.73

>>106-107のやり方が使うときにはスッキリできそうだなぁ
>>108
二つ目のやつって色々出来そうに見えて汎用的にならないのが惜しい

**デフォルトの名無しさん** · 2018/07/24(火) 23:53:36.51

動的型言語「呼んだ？」

**デフォルトの名無しさん** · 2018/07/24(火) 23:59:34.61

よく調べないで書くけどMapでしか渡せないならMapの値にクラス突っ込めないの

**デフォルトの名無しさん** · 2018/07/25(水) 00:05:15.27

普通に data class 書くかイヤなら動的型使え案件だな

**デフォルトの名無しさん** · 2018/07/25(水) 00:32:44.86

動的型付言語でもMapから取り出したインスタンスに何かするにはそのインスタンスの型のチェックは必要なんだから、
KotlinでもAnyの変数に取り出した後、何かするとき型チェックすればいいのでは？

**デフォルトの名無しさん** · 2018/07/25(水) 00:41:37.28

>>109
汎用的ってどういうこと？

**デフォルトの名無しさん** · 2018/07/25(水) 02:34:30.53

一回シリアライズするとか正気かよ。

inline fun <ｒｅｉｆｉｅｄ T: Any> ｃａｓｔ(any: Any): T = T::ｃｌａｓｓ.ｊａｖａＯｂｊｅｃｔＴｙｐｅ.ｃａｓｔ(any)

val i = ｃａｓｔ<Int>(ｍａｐ["hoge"])

**デフォルトの名無しさん** · 2018/07/25(水) 02:52:17.20

Mapのキーの文字列に対して格納されてる型が決まってるのか
エラーチェック無しで間違ったのが入ってたら例外で良いなら、そんな感じにキャストでいいかもね

**デフォルトの名無しさん** · 2018/07/25(水) 06:23:31.29

全角読みにくい

**デフォルトの名無しさん** · 2018/07/25(水) 07:17:57.17

>>113
動的型付言語は人間が頭の中で実際の型を把握してればコード上では型チェック不要だよ

Ruby
map = {}
map["hoge] = "今は文字列"
map["hoge"] = 100 #今は整数
map["hoge"] = [1,2,3] #今は整数の配列

map["hoge"].each{|i| puts i.to_s} # 今入ってるのは整数の配列だと人間が把握してるので適正なコード

**デフォルトの名無しさん** · 2018/07/25(水) 07:34:47.16

>>117
半角のまま貼り付けたら弾かれたんだ。

**デフォルトの名無しさん** · 2018/07/25(水) 07:40:45.40

>>115
明示的にキャスト、間違ってたら実行時例外でいいなら as でよくね

val map = HashMap<String, Any?>()
map["hoge"] = 10
map["hage"] = "zura,katsura"
map["hoge"] = map["hage"]

val list = (map["hage"] as String).split(',')
println(list) // [zura, katsura]

**デフォルトの名無しさん** · 2018/07/25(水) 08:28:43.96

Kotlinスレが珍しくKotlinの話してるのか

**デフォルトの名無しさん** · 2018/07/25(水) 10:22:42.75

元の>>99についての話なら「キャストなし」が前提なのでは

とはいえシリアライズやGSONなら型定義が必須だろうから
キャストより手間増える気がする

**デフォルトの名無しさん** · 2018/07/25(水) 10:56:38.61

使うたびにキャストするのが面倒くさいって話なら一度定義しとけばあとはそのまま使えるgsonはアリじゃね

**デフォルトの名無しさん** · 2018/07/25(水) 11:39:23.46

てか別にGsonなんて使わなくてもHashを渡して初期化したら中でいい感じにkeyごとにキャストしておいてくれるラッパークラス作れば良いのでは

**デフォルトの名無しさん** · 2018/07/25(水) 12:12:16.20

結局取り出すときに型がわかってるようにするには事前定義が必須と

**デフォルトの名無しさん** · 2018/07/25(水) 12:55:48.93

せやな

**デフォルトの名無しさん** · 2018/07/25(水) 14:31:05.88

当たり前の話
嫌なら静的型付けなんてやめちまえ