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/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

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

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

性的片付けならお手伝いします。

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

Mapから特定のキーで取り出した値の型をプログラマが知っている場合だけでしか使えなくて、型がわからないなら型チェックが必要になり、そうするとスマートキャストが使えるので現状のままで問題ない事になる。
型チェックなしで使えるようにできたとしてもやはりバグの温床になりそうだというのもある。(しかも見つけにくいバグにならないか？)

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

特にKotlinの場合はJavaのウンコ仕様のせいでジェネリクスの型引数を安全にダウンキャストできないからな

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

やっぱJetbrain VM作ってよ～

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

>>131
何のメリットが？

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

そもそもVM利用してるのってJavaの遺産利用する為だしな

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

資産ではなく遺産

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

>>99
https://ideone.com/Bxe3Vj

**デフォルトの名無しさん** · 2018/07/26(木) 20:21:16.47

>>135
map["hoge"] as String → map.get<String>("hoge")
map["fuga"] as Int → map.get<Int>("fuga")
無 → inline fun <reified T> HashMap<String, Any?>.get(key: String) = get(key) as T

ただのキャストよりコード量が増えて危険な操作であることがわかりにくくなっただけやんけ

**デフォルトの名無しさん** · 2018/07/27(金) 02:00:17.48

全然関係ない話

これが出来る事を知らなかった。

val s = "abc"
println("${s + "xyz"}")

ダブルクォーテーションで括った中にダブルクォーテーションで括った文字列がある状態なのに問題なくコンパイルも実行もできる。
${ ... } はコンパイル時に特別扱いしてたんだな。

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

>>137
マジか、知らなかった。
まあやることはあまりないだろうがw

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

{}の中はプラグラムのコードやからな。
それだけやで

**デフォルトの名無しさん** · 2018/07/27(金) 08:06:17.19

一番内側のデリミタが来るまでは外側のデリミタはマスクされて見えないという話

**デフォルトの名無しさん** · 2018/07/27(金) 08:36:58.60

むしろコンパイル時じゃなかったらビビる
evalがある言語じゃないんだから

**デフォルトの名無しさん** · 2018/07/27(金) 08:45:57.59

もちろんネストも出来る

Kotlin　　　https://ideone.com/9oQrPl
Groovy　　https://ideone.com/PkZexd
Swift　　　https://ideone.com/vCuTyE
bash　　　https://ideone.com/9GW6lT

**デフォルトの名無しさん** · 2018/07/27(金) 18:32:30.58

>>141
そんな威張るなよ

**デフォルトの名無しさん** · 2018/07/27(金) 18:38:45.51

そんな僻むなよ

**デフォルトの名無しさん** · 2018/07/28(土) 13:18:16.11

unit testしたいんですが
junit って標準モジュールじゃないんですか？

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

じゃないです。

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

ようやくKotlin1.3の話が出てきた。
ttps://blog.jetbrains.com/kotlin/2018/07/see-whats-coming-in-kotlin-1-3-m1/

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

operator で何も返さない Unit のやつを作るとどうなるかを実験していて気づいたこと。
例えば plus() って + 記号が出てきただけで呼ばれるわけで、そうなると + 記号だけで中身を書き換える事も可能になるんだな。

https://paiza.io/projects/wtY0TgCLyLhRsls2-6wcuQ

**デフォルトの名無しさん** · 2018/07/29(日) 08:59:34.65

そりゃまあただのメソッド呼び出しを糖衣構文だし

**デフォルトの名無しさん** · 2018/07/29(日) 09:51:20.17

>>149
これができるのなら Unit ではない演算子の結果を捨てるような式はエラーにして欲しかった。

**デフォルトの名無しさん** · 2018/07/29(日) 10:47:26.84

DSLに使うからそれは困る

**デフォルトの名無しさん** · 2018/07/30(月) 18:02:59.40

JetBrains のサイトに StringBuilder.set メソッドのドキュメントがない事に気づいた。
いやググると見つかるので正確にはあるのだが、どこからリンクされているかがわからない。
普通に考えるとこれは StringBuilder のページからなんだろうが、それはない。getならある。

**デフォルトの名無しさん** · 2018/08/01(水) 15:30:30.04

JavaFX+Kotlinでクロスプラットフォームのアプリ作ろうと思ったけど、
やっぱ今からだとElectronの方がいいのかな
SDKからも切り離されたし

**デフォルトの名無しさん** · 2018/08/01(水) 16:27:09.30

TornadoFX使ってみてよ

**デフォルトの名無しさん** · 2018/08/01(水) 17:14:08.32

竜巻外為良さそうだけど、そもそもJavaFXが流行ってない気が

**デフォルトの名無しさん** · 2018/08/01(水) 17:17:06.60

現時点で流行ってないし、java自体がこの状況で今から人気が出てくるとも思えないよなあ
electronかみんな大好きXamarinでも使った方がいいだろう

**デフォルトの名無しさん** · 2018/08/01(水) 22:35:46.35

TornadoFX良かった。JavaFXが切り離されさえしなければ...

**デフォルトの名無しさん** · 2018/08/01(水) 23:16:43.13

トーナードは良いものだよ。
JavaFX自体が消滅しそうだけど

**デフォルトの名無しさん** · 2018/08/02(木) 00:14:03.14

tornado の発音はトーネイドに聞こえるが・・・

**デフォルトの名無しさん** · 2018/08/02(木) 00:40:41.05

なんでJavaFXって人気ないの？
Electronが人気すぎるだけ？
Electronコード隠蔽できないから嫌なんだけどな

**デフォルトの名無しさん** · 2018/08/02(木) 01:22:59.89

>>160
なんでって、Javaだからだよ
有史以来、FXに限らずクライアントJavaに人気があったことなど無い

**デフォルトの名無しさん** · 2018/08/02(木) 02:34:55.79

Android で大人気だけどなw

**デフォルトの名無しさん** · 2018/08/02(木) 02:35:51.35

javafxscript用の設計だったからね
script潰れてjava向けに再設計とか時間かけすぎなんだよ

**デフォルトの名無しさん** · 2018/08/02(木) 06:11:52.44

アンドロイドせいでjava/kotlinを書かざるを得ない迷惑なはなし

**デフォルトの名無しさん** · 2018/08/02(木) 06:43:03.26

>>164
C++やJavaScriptでも書けるだろ

**デフォルトの名無しさん** · 2018/08/02(木) 07:38:05.58

C#で書けるだろ、忘れるな

**デフォルトの名無しさん** · 2018/08/02(木) 08:27:55.22

はいxamarinネタ禁止

**デフォルトの名無しさん** · 2018/08/02(木) 13:16:08.31

加速度センサーに木星や土星の重力加速度があるのですが、何に使うんでしょうか？

**デフォルトの名無しさん** · 2018/08/02(木) 13:35:16.77

なんかの実験用じゃない

**デフォルトの名無しさん** · 2018/08/02(木) 13:39:12.92

木星や土星へ行った時のため

**デフォルトの名無しさん** · 2018/08/02(木) 15:31:09.75

たまに使うよね

**デフォルトの名無しさん** · 2018/08/02(木) 15:55:49.44

俺も前職で何度か土星行ったから、そういう時は役に立った

**デフォルトの名無しさん** · 2018/08/02(木) 16:26:00.89

どしぇー

**デフォルトの名無しさん** · 2018/08/02(木) 17:47:49.29

10年前にJavascriptとDA PUMPが再ブレークすることを予想してた奴が居たら凄いと思う

**デフォルトの名無しさん** · 2018/08/02(木) 20:26:30.99

Electron + Kotlin/JS というのはアリ? というかしている人いる?

**デフォルトの名無しさん** · 2018/08/02(木) 20:41:24.62

ElectronならTypeScriptでいいだろ

**デフォルトの名無しさん** · 2018/08/02(木) 21:35:16.65

プロシュート兄貴を見習え

**デフォルトの名無しさん** · 2018/08/02(木) 22:16:27.96

>>175
ReactNativeをKotlin/JSで書こうとして死亡してた人なら知ってる。
出来ないことはない、ってレベルらしい

**デフォルトの名無しさん** · 2018/08/03(金) 16:55:37.97

Javascriptが流行ってるのって言語の作りが良いからとかじゃなくて、結局はブラウザで動くからなんだよな
だから、誰かがことりんが動くブラウザを作ればことりん流行ると思う

**デフォルトの名無しさん** · 2018/08/03(金) 16:57:00.14

>>179
君に任せた

**デフォルトの名無しさん** · 2018/08/03(金) 17:51:01.66

コトリンが動くブラウザをお前らが作っても流行らんよ

**デフォルトの名無しさん** · 2018/08/03(金) 18:04:24.79

あ、そうか。JavaScriptの代わりにKotlinスクリプトが動けばいいんじゃないか。そうすればわざわざJavaScriptに変換しなくて済む。

**デフォルトの名無しさん** · 2018/08/03(金) 19:10:58.88

GoogleがDartで、それやろうとして、結局、あきらめたじゃん。
Dart自体は、Fuchsiaで復活するみたいだけど。

**デフォルトの名無しさん** · 2018/08/03(金) 19:29:20.15

dartもいい言語じゃねぇけど、JSよりかはましだからな。flutter人気でてdart使われるようになったら、dartのchromeブラウザ搭載計画を復活させて欲しい

**デフォルトの名無しさん** · 2018/08/03(金) 19:32:54.71

wasmにDOM/GCが搭載されれば色んな言語からの需要があるだろうしそれほど夢物語でもない
kotlinがその中で天下取れるかはまた別の話だけど

**デフォルトの名無しさん** · 2018/08/03(金) 19:33:36.87

Chromeだけ動くようになったとしても他のブラウザが追随して、かつそれ以前のバージョンが駆逐されるまで待たないと実用できないからな。

それにDart自体がクソみたいな言語であることは変わらないから、多大なコストかけてまで乗り換えたくはないな

**デフォルトの名無しさん** · 2018/08/03(金) 19:38:42.60

TypeScriptという手軽でまあまあなソリューションが広まって、なんかもういいんじゃねという空気だよね

**デフォルトの名無しさん** · 2018/08/03(金) 20:00:01.04

プログラミング言語は素晴らしいから広まるんじゃないのだということを我々はこの30年でイヤというほど味わったのでるふぁい

**デフォルトの名無しさん** · 2018/08/03(金) 20:25:03.99

でるふぁい

**デフォルトの名無しさん** · 2018/08/03(金) 21:06:23.69

Algol

**デフォルトの名無しさん** · 2018/08/03(金) 23:27:02.39

WebもアプリもKotlinよりTypescriptだろうか

**デフォルトの名無しさん** · 2018/08/03(金) 23:43:06.58

まあそうだね
オラクルの件のせいで今後は(Kotlinが使えるような会社においては)Javaプラットフォームが積極的に選ばれることももう無くなるだろう
どうしてもJavaプラットフォームを使わざるを得ない事情があるときのマシな選択肢としての限定的なポジションに落ち着いていくんだろうね

**デフォルトの名無しさん** · 2018/08/04(土) 07:38:33.47

Kotlinは贔屓目でもなんでもなく、Java環境で動く素晴らしいJava代替物なのだが
その肝心の「Java環境でなければならなかったこと」が唐突に外部要因で縮小し始めており回復の理屈もないのだ…
現時点でJavaに業務で縁のない人はちょっと立ち止まったほうがいいかもしれん
Androidでプログラミングしたい？ Unity使えUnity

**デフォルトの名無しさん** · 2018/08/04(土) 09:36:50.04

一年前のだけど興味深いディスカッション

なぜKotlin Native？
https://discuss.kotlinlang.org/t/2275/

JetBrainsチームのコメントに気になる文言もある
Rock54のせいで引用出来ないけど18と22

**デフォルトの名無しさん** · 2018/08/04(土) 09:44:43.94

今後の状況次第ではJava環境からの脱出口になるから
もっとKotlin/Nativeにパワーを

Kotlin/Native v0.8 released
https://blog.jetbrains.com/kotlin/2018/07/kotlinnative-v0-8-released/

**デフォルトの名無しさん** · 2018/08/04(土) 10:09:54.85

言っちゃ悪いけど、開発言語を前提にして物事を考えるのってエンジニアとしてはだいぶ低レベルな段階だよ
そのレベルの連中が多数派を占めるほどにはまだKotlinの裾野は広がってないと思う
梯子外されるのがもうちょっと遅かったらもしかしたらとは思うけど、残念だね

**デフォルトの名無しさん** · 2018/08/04(土) 10:31:19.81

仕事と趣味は別という発想が出てこない君はエンジニア以前に社会人としてとても低レベルだね