Kotlin [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/02/27(土) 01:46:01.68

JetBrainsが開発した期待の新言語Kotlinについて語りましょう
https://kotlinlang.org

**デフォルトの名無しさん** · 2017/04/16(日) 13:23:05.16

一つのクラスに複数のアノテーション持てない感じ？

**デフォルトの名無しさん** · 2017/04/18(火) 07:19:21.21

このスレで言うのもなんだが、初心者の質問はTwitterで投げるのがいいよ
普及させたい人が定期的に検索して拾ってくれるから

**115** · 2017/04/22(土) 21:58:39.69

>>114
オブジェクトのように「フィールド」に「値」を状態として持つのではなく、
coroutineは「コード上」に「まだ実行されていない処理」を状態として持つから
複雑で分かりにくいんじゃないかなと思いました。

>>116
coroutine自体がステートマシンだと書いてあるものを見たのですが、
ステートマシンが局所化されるモナドのような何か?(わかってない)

**デフォルトの名無しさん** · 2017/04/23(日) 10:19:21.32

suspend関数ってコルーチンの中でしか使えないってことは、そこらじゅうlaunchの類だらけになるってこと？笑
まだ滅多に使用例のってるブログとかみかけないね。
生き残れるのか？これｗ

>>119 https://github.com/pljp/kotlin-coroutines/blob/japanese_translation/kotlin-coroutines-informal.md#状態マシン

**デフォルトの名無しさん** · 2017/04/28(金) 17:34:29.34

ことりん擬人化まだ？

**デフォルトの名無しさん** · 2017/05/01(月) 23:00:23.52

Rubyの、p, pp みたいに、自動的に、コンテナ内を展開して、
中のオブジェクトを、コンソールに表示してくれる、デバッグ用関数はありますか？

p コンテナ・オブジェクト

**デフォルトの名無しさん** · 2017/05/04(木) 00:18:07.49

ない
そんなもんIDEのデバッガで止めて見ればいいだろ

**デフォルトの名無しさん** · 2017/05/04(木) 00:39:59.73

それはダサいわ

**デフォルトの名無しさん** · 2017/05/13(土) 22:26:26.42

なんか折りたたみすぎるんだよな～

**デフォルトの名無しさん** · 2017/05/18(木) 03:33:23.69

大勝利ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ !!!!

**デフォルトの名無しさん** · 2017/05/18(木) 03:35:35.85

きたな

**デフォルトの名無しさん** · 2017/05/18(木) 03:38:32.99

まじか

**デフォルトの名無しさん** · 2017/05/18(木) 08:19:21.98

アプデかなんか来たの？

**デフォルトの名無しさん** · 2017/05/18(木) 08:34:44.83

Androidでのファーストクラスサポートだそうですよ

**デフォルトの名無しさん** · 2017/05/18(木) 08:35:35.63

Today, at the Google I/O keynote, the Android team announced first-class support for Kotlin.

だって。

**デフォルトの名無しさん** · 2017/05/18(木) 09:08:10.23

ファーストクラスってなんですか？

**デフォルトの名無しさん** · 2017/05/18(木) 09:13:30.93

ビジネスクラスより上

**デフォルトの名無しさん** · 2017/05/18(木) 09:37:46.74

例の訴訟絡みでjvm捨てると思ってたんだがなあ

**デフォルトの名無しさん** · 2017/05/18(木) 10:06:03.05

記念アゲ (・8・)

**デフォルトの名無しさん** · 2017/05/18(木) 12:11:08.36

Android Studioで標準サポートになる、つうことだろ。

**デフォルトの名無しさん** · 2017/05/18(木) 12:12:50.95

AndroidがKotlinサポートか
Java使わなくていい場面増えるのは歓迎だけど
C#のが良かった

https://blog.jetbrains.com/kotlin/2017/05/kotlin-on-android-now-official/
http://jp.techcrunch.com/2017/05/18/20170517google-makes-kotlin-a-first-class-language-for-writing-android-apps/

**デフォルトの名無しさん** · 2017/05/18(木) 12:17:09.11

GWにkotlin始めて書きやすいなと思ってた俺大勝利

**デフォルトの名無しさん** · 2017/05/18(木) 12:38:42.71

>>137
今までのJava資産を活かしながらシームレスに移行できる、というのが大きい。
その意味でc#はありえん。

**デフォルトの名無しさん** · 2017/05/18(木) 12:57:50.54

いまJavaを使ってる人を救うことを考えたらまずはKotlinだろうね

**デフォルトの名無しさん** · 2017/05/18(木) 13:16:17.63

まじかよ
コトリン大好きな俺大勝利じゃん
祝杯や

**デフォルトの名無しさん** · 2017/05/18(木) 13:21:33.03

やったぜ

**デフォルトの名無しさん** · 2017/05/18(木) 13:23:06.77

えっちだぁw

**デフォルトの名無しさん** · 2017/05/18(木) 15:12:54.92

日本Kotlinユーザグループ代表、長澤太郎
Kotlinスタートブック -新しいAndroidプログラミング、2016

WEB+DB vol.94 の特集が、Kotlin, Electron

m, 10
a, 5
m, 2

こういう行区切りのデータがある時、文字列・数値の順番で、ソートするにはどうするの？

**デフォルトの名無しさん** · 2017/05/18(木) 15:28:16.59

KotlinじゃなくSwiftでも良いのにな
確か、Android向けのクロスビルドができるようになってたろ

**デフォルトの名無しさん** · 2017/05/18(木) 16:57:05.60

AppleがGoを公式採用するくらいあり得ないことだな

**デフォルトの名無しさん** · 2017/05/18(木) 17:15:26.94

>>145
今までのjava資産を考えるとありえん。
appleは悪い意味でおかしい。

**デフォルトの名無しさん** · 2017/05/18(木) 18:29:24.60

競技プログラミングでKotlinを覚えるか…

**デフォルトの名無しさん** · 2017/05/18(木) 23:54:53.47

>>70
念願かなったね。おめでとう。

**デフォルトの名無しさん** · 2017/05/19(金) 08:25:10.64

>>144 自己レス
class Person(val age: Int, val name: String) { }

val mlist: MutableList<Person> = mutableListOf( );

mlist.add(Person(25, "Tom"));
mlist.add(Person(25, "Dave"));
mlist.add(Person(20, "Kate"));
mlist.add(Person(20, "Alice"));

val sortedList = mlist.sortedWith(compareBy({ it.age }, { it.name }))

sortedList.forEach {
println("${it.age} : ${it.name}")
}

出力
20 : Alice
20 : Kate
25 : Dave
25 : Tom

**デフォルトの名無しさん** · 2017/05/19(金) 13:20:04.25

ニュース見て始めて半日くらいの調べもの堪え性のない人が質問です！
それはそうと初心者スレとか質問スレとかあってもいいかもしれないですね！

>>> var list = listOf(10, 20, 30)
>>> list[1] + 5
25
>>> var map = mapOf(1 to 10, 2 to 20, 3 to 30)
>>> map[1] + 5
error: infix call corresponds to a dot-qualified call 'map[1].plus(5)' which is not allowed on a nullable receiver 'map[1]'. Use '?.'-qualified call instead
>>> map[1]?.plus(5)
15
入ってる数字をあとで計算とかに使いたいだけなんですがどこの考え方間違ってるんでしょうか

**デフォルトの名無しさん** · 2017/05/19(金) 20:24:00.83

>>70
おめ

**デフォルトの名無しさん** · 2017/05/19(金) 20:34:19.80

>>71
これは恥ずかしいwwww

**デフォルトの名無しさん** · 2017/05/19(金) 22:29:26.32

じゃ今後のAndroidのライブラリにはKotlinで書かれてるものの出てくるのかな？

**デフォルトの名無しさん** · 2017/05/20(土) 00:38:31.20

それはないだろう

**デフォルトの名無しさん** · 2017/05/20(土) 02:32:08.53

>>151
map[何々]が、nullable だから。
map[1]は存在するけど、map[4]なら存在しない

map[1].plus(5)なら、map[1](レシーバー)がnullableだから、
null.plus(5)の場合にバグるから、?. null許容演算子を使う

**デフォルトの名無しさん** · 2017/05/20(土) 15:30:08.83

Javaの仕様がそのまま引き継がれてるんだな
Listのgetのインデックスが範囲外だとIndexOutOfBoundsException例外で
Mapのgetのキーが存在しない場合は例外じゃなくてnull返すのね

**デフォルトの名無しさん** · 2017/05/20(土) 15:41:06.41

getOrNullとかあるよ

**デフォルトの名無しさん** · 2017/05/20(土) 19:38:14.41

Android StudioでのIntelliJ Kotlinプラグインが公式サポートされただけでAndroid System LibにKotlinクラス群が入ったわけじゃないんだよなぁ

>>154
今までと変わらずやる気になれば出るし、やる気にならなければ出ない程度かと
別段メリットがあるようには思えないけど、誰かKotlin Androidライブラリプロジェクトテンプレート作ってくれよ

**デフォルトの名無しさん** · 2017/05/20(土) 20:11:09.01

企業内での使用はGoogle公式かどうかですごい影響あるよ

**デフォルトの名無しさん** · 2017/05/21(日) 10:31:28.30

これをきにコトリンを始める人がいっぱいいそうだが
ほとんど人が挫折するんだろうな

**デフォルトの名無しさん** · 2017/05/21(日) 10:35:53.77

こんな簡単な言語で挫折する要素とは

**デフォルトの名無しさん** · 2017/05/21(日) 10:40:32.81

Kotlin言語そのものは難しくないがJavaの言語に加えて
Javaのライブラリまで含めて覚えないといけなそうだから
C#より敷居が高い

**デフォルトの名無しさん** · 2017/05/21(日) 11:08:54.99

kotlinにはtypescriptのtsserverみたいに補完機能はないんでしょうか？

**デフォルトの名無しさん** · 2017/05/21(日) 11:33:04.16

第一級開発言語に指定したんやからfwは全てkotlinラッパを出すやろ

**デフォルトの名無しさん** · 2017/05/21(日) 12:33:48.18

?なvarをif != null したら!!いらないようにしてほしいな～
valに入れ直すのはスマートじゃないよ

**デフォルトの名無しさん** · 2017/05/21(日) 13:24:08.34

>>156
似たようなとこで詰まってた
Nullableでご安全にする理屈はわかるけど連想配列の利用法としては煩雑だね
覚えとくしかないか
それともこのへん便利な格納構造があるのかな

**デフォルトの名無しさん** · 2017/05/21(日) 18:45:53.63

>>> var map = mapOf(1 to 10,2 to 20)
>>> map[3]
null
>>> var list = listOf(10,20)
>>> list[3]
java.lang.ArrayIndexOutOfBoundsException: 5
at java.util.Arrays$ArrayList.get(Arrays.java:3841)
>>157の言う通り、究極的にはこのしょーもない内部仕様のせいである
この仕様を知ってるKotlinがmap作った時点で全要素Nullableにしてくれてるのだね

>>> var value = map[2]
>>> value
20
>>> value + 5
error: infix call corresponds to a dot-qualified call 'value.plus(5)' which is not allowed on a nullable receiver 'value'. Use '?.'-qualified call instead
>>> var value:Int = map[2]
error: type mismatch: inferred type is Int? but Int was expected
このへんも、Null安全のない言語から来た人はふんす！！ってなると思われ

**デフォルトの名無しさん** · 2017/05/21(日) 20:26:44.09

>>163
C#文法とC#ライブラリを学習するよりは楽そう

>>165
Java APIをKotlin APIに透過的に見せるからラッパーの用意すら要らんでしょ

**デフォルトの名無しさん** · 2017/05/21(日) 20:46:52.64

最終的に訴訟のネタにもなってるjavaを切り離す方向まで行かないんですかね。

**デフォルトの名無しさん** · 2017/05/21(日) 21:44:40.19

VMの問題なんだからいまさらどうしようもないだろ。

**デフォルトの名無しさん** · 2017/05/21(日) 22:54:56.67

Ruby, JS などで、メソッドチェーンすると、
nil オブジェクトから、メソッドを呼べないと言う、
No Method Error なんて、しょっちゅう起こるし、

メソッドチェーンはテストも、しにくい

**デフォルトの名無しさん** · 2017/05/22(月) 01:22:13.90

素のkotlinでは使えるけどAndroidのkotlinでは使えないのってある？

**デフォルトの名無しさん** · 2017/05/22(月) 01:48:31.03

Nullableかどうかは書き手が決められるのがステキとか言っておきながら
mapOfだと"暗黙の"Nullableになるように見えるのが初心者的にキモいという主張だろう
誰もNullableの有用性の議論などしてない
読点君には理解できんだろうが

**デフォルトの名無しさん** · 2017/05/22(月) 06:16:11.80

>>170-171
VMじゃなくAPI(ライブラリ実装)の問題でしょ
Sun(現Oracle)の作った全Java APIを放棄してKotlinで一から作れば訴訟問題からは無関係になれる

まぁ、GoogleもJetbrainsもお互いに「お前がやれ」とか思ってそうだけど
Google: KotlinはJetbrainsのモノなんだから、JetbrainsがKotlin APIを整備するべき
Jetbrains: Java訴訟はGoogleの問題なんだから、GoogleがKotlin APIを整備するべき

**デフォルトの名無しさん** · 2017/05/22(月) 08:14:55.23

map を実装する場合、普通は、2種類書く

そのキーが無い場合、
null を返すものと、例外をthrow するもの

nullable になるのは、null を返すもの

**デフォルトの名無しさん** · 2017/05/22(月) 08:34:20.91

>>175
VMの方のAPIだよ。
言語の方のAPIだけの問題なら、OpenJDKだけで解決してしまうだろが。

**デフォルトの名無しさん** · 2017/05/22(月) 09:45:07.45

>>177
確かそのapiのインターフェース自体に著作権があるというのがoracleの主張だったはず

**デフォルトの名無しさん** · 2017/05/22(月) 09:46:09.30

OpenJDKにもVM実装は含まれてるんだけどなw
Oracle JVMとOpenJDK JVMで微妙に要件や振る舞い違うって業界の人は頭抱えるけどまぁ誤差か

**デフォルトの名無しさん** · 2017/05/22(月) 09:46:23.44

擬人化まだかよ
無能どもめ

**デフォルトの名無しさん** · 2017/05/22(月) 09:52:42.83

>>175
Androidのapiインターフェースの話をしてるんだからgoogleじゃない？
でもjavaと切り離すなんてできないだろうから、少しずつやってくしかないね。
コレクション系の独自実装とか始まったりして
swiftもobjective-cの文字列型とswiftの文字列型があってapiインターフェース呼び出しの際に暗黙の型変換が行われてた。
そんな感じになるのかな。かなりキモいけど

**デフォルトの名無しさん** · 2017/05/22(月) 18:40:23.05

「apiインターフェース」の「頭痛が痛い」みたいな表現、嫌いじゃない:D

>>160
その昔、Apple公式だからという点のみで流行ったSwiftという言語があってな・・・
あれも技術を知らない企画屋がそんな感じで企業内採用を提案したんだよな、嫌な事件だったね

**デフォルトの名無しさん** · 2017/05/23(火) 19:42:46.96

null非許容って使ってみると地味に結構不便だな…
今までとは根本的に設計方針を変えなきゃならないものがあるなぁ…

**デフォルトの名無しさん** · 2017/05/23(火) 19:49:01.45

var a : String? = null

**デフォルトの名無しさん** · 2017/05/23(火) 20:27:48.65

型安全でないnull使うより、その型のnull定数を定義するほうが楽だよ。

**デフォルトの名無しさん** · 2017/05/23(火) 20:49:32.53

val hoge;
{

**デフォルトの名無しさん** · 2017/05/23(火) 21:06:38.96

null参照の概念は10億ドル単位の過ちってそれ一番言われてるしなw
偉人の言葉を信仰心と共に信じるべし

**デフォルトの名無しさん** · 2017/05/23(火) 21:36:52.74

ぬるぽ

**デフォルトの名無しさん** · 2017/05/24(水) 01:18:07.88

>>183
?使うだけなのに何言ってんの？
大昔の案件で引数には必ずnullチェックを入れるというコーディング規約があって、保守性は下がるし規約に従わないやつはいるしで散々だった。

**デフォルトの名無しさん** · 2017/05/24(水) 12:26:54.17

intellij、if式を折りたたまないようにするオプションはどこですか？

**デフォルトの名無しさん** · 2017/05/24(水) 12:44:50.63

>>189
たとえばintefaceのnotnullなプロパティを亜種的なクラスでnullableにオーバーライド、できないよねぇ。
個人レベルの開発ならそこらへんの曖昧さはかえって便利な場合もあったんだけどね。
まぁ最初から全部nullableにしちゃえば済む話だが9割の非nullに全部?なり!!を付けるのはキモい。
javaコードをそのまんまkotlinコードに移行は、できなくはないけどキモいコードになる。

**デフォルトの名無しさん** · 2017/05/24(水) 14:28:45.40

　　Λ＿Λ　　＼＼
　（　・∀・）　　　|　|　ｶﾞｯ
　と　　　　）　　 |　|
　　Ｙ　/ノ　　　人
　　　 /　）　　 < 　>_Λ∩
　＿/し'　／／. Ｖ｀Д´）/
　（＿フ彡　　　　　　　/　←>>188

**デフォルトの名無しさん** · 2017/05/24(水) 15:15:47.70

>>191
わざわざnullableなプロパティを含むインターフェースを使う意味がわかんない。ちゃんとnullチェックして渡せば良いじゃない。

**デフォルトの名無しさん** · 2017/05/25(木) 00:19:31.03

>>193
自分もそんなコードが欲しくなるとは予想しなかったけどな笑
nullであることを利用して動作変える派生クラスをkotlin化しようとして躓いたわ。
結局設計を変えることで対応したけどね。javaで使えてたトリッキーな手は使えなくなった不便さがあるね、便利さの陰に。
まぁ慣れの問題だが。

**デフォルトの名無しさん** · 2017/05/25(木) 04:40:51.77

androidだとonCreateで初期化するような変数はnullableにしなきゃいけないのかと思ってたけど、lateinitってあるのね
個人的にはそこそこ使うから@とかの記号にしてほしかったけど

**デフォルトの名無しさん** · 2017/05/25(木) 06:20:09.08

プロパティが、最初からデフォルト値を持っていたら、ダメなのか？

どうしても、nullが必要なのか？

**デフォルトの名無しさん** · 2017/05/25(木) 08:51:21.17

nullオブジェクト使わないの？

**デフォルトの名無しさん** · 2017/05/25(木) 09:21:48.18

関数の戻り値の型ならnullable欲しいな
戻り値がnullになるとき毎回exceptionをthrowするのかって話

**デフォルトの名無しさん** · 2017/05/25(木) 09:23:32.29

え？ww

**デフォルトの名無しさん** · 2017/05/25(木) 09:37:46.25

例えば数値を文字列として格納してるデータをファイルとかDBとかから取り出すとき
その値は数値としてしか使わないけどもしかしたらnullな場合もある
getter関数作るのにgetterでは必ず文字列として取得して変換可能か判断してから数値にする処理を毎回するか変換できなかったらcatchするのか

そんな場合なnullableがあれば外からみた関数の使い方はシンプルにできる

**デフォルトの名無しさん** · 2017/05/25(木) 11:19:50.16

だからnullオブジェクトを用意して使えって。
型安全でないnullなんか窓から投げ捨てろ。

**デフォルトの名無しさん** · 2017/05/25(木) 11:20:19.76

入力欄のオプショナルな項目か

携帯電話を持っていれば、その番号を記入して、みたいな奴か

**デフォルトの名無しさん** · 2017/05/25(木) 11:26:27.67

頭が時代についていってないようだなw

**デフォルトの名無しさん** · 2017/05/25(木) 22:55:58.94

元々はアドレスだったことを思い出せば功罪がわかる

**デフォルトの名無しさん** · 2017/05/26(金) 05:24:14.29

>>196
同じようなことを考えたことがあったけど、「実行時エラーは悪」という考えにとらわれると、
間違った値(デフォルト値)のままエラー無しに処理が進んでしまうのは実行時エラーよりたちが悪い
ということを忘れがちになる。
>>197
使用頻度を考えるとnullオブジェクトをいちいち定義するよりnullチェックのほうがましな
変数の方が多いと思われる。
また、nullオブジェクトはどんな状況で使われても適切な結果を返すように実装しなければ、
上で述べたデフォルト値の問題を起こすことになるから、ミスのないデフォルトを
設定すること自体が難しい場合もあると思う(使用経験が少ないからわからない)。

**デフォルトの名無しさん** · 2017/05/26(金) 07:38:30.45

>>205
今時はなるべく完全コンストラクタを使って最初に一括で初期化し、
後は一切変更できないクラス設計が好まれるんだよ
C#は見境なく大量のgetsetプロパティを持つクラスを定義するバカが多いけど

**デフォルトの名無しさん** · 2017/05/26(金) 09:51:12.09

kotlin/nativeに期待

**デフォルトの名無しさん** · 2017/05/26(金) 10:10:41.46

nullチェックはもうちょっと痒いところまで手が届くといいね
たとえば if(a == 0 && b?. == "hoge") {...} で2つめはnullならパスしてくれる
みたいに書けたら便利

**デフォルトの名無しさん** · 2017/05/26(金) 10:24:21.56

nullを使わなければいいと思うよ

**デフォルトの名無しさん** · 2017/05/26(金) 11:15:12.27

>>205
コンパイルエラーにできるものを実行時に処理するのは良くない設計だな。
型無しのnullを使うとコンパイルエラーに出来なくなる。
nullオブジェクトでも実行時エラーは処理できるから、必要ならそうすりゃいいし。

**デフォルトの名無しさん** · 2017/05/26(金) 11:16:41.50

いぐざくとりいい！

**デフォルトの名無しさん** · 2017/05/26(金) 12:12:06.77

>>209 と、いわれても既存APIにはnullableだらけだからなぁ

**デフォルトの名無しさん** · 2017/05/26(金) 12:28:01.13

そのAPIの中はそれで良いと思う
今後作るAPIについては別に過去をなぞる必要はないとも思うよ

**デフォルトの名無しさん** · 2017/05/26(金) 12:46:21.42

>>207
これってiosもうごくの？

**デフォルトの名無しさん** · 2017/05/26(金) 22:05:46.36

Kotlin/NativeをAndroid(NDK)で動かしたい

**205** · 2017/05/27(土) 00:21:30.12

>>210
およそ
nullがコンパイルエラーになる > 適切に設計されたnullオブジェクト >
nullチェック > 実行時NPE > 不適切なnullオブジェクトでエラー無しに誤った処理が進む

という順位なので>>210とは特にそれほど見解の相違はないと思う。
nullオブジェクトは必ず容易かつ適切に設計できることを暗黙の前提とするかどうかが相違点かな。