Kotlin 2

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

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

前スレ
Kotlin
http://mevius.5ch.net/test/read.cgi/tech/1456505161/

**デフォルトの名無しさん** · 2018/02/21(水) 19:30:46.29

>>661
意図はないけど、null安全とかいっておきながらkotlin側だけでnull入るコード書けるのまずいような気がする。
いや、プロパティの初期化方法がうざくて色々調べてたら気づいただけ。

**デフォルトの名無しさん** · 2018/02/21(水) 19:35:19.91

プロパティ宣言すると初期値与えろってうるさいんだけど、うるさいのはいいんだけど初期値の与え方が
val str: String = プロパティイニシャライザ
プロパティイニシャライザ以外、bakcingFieldに直接与える方法ないの？？
>>659だって、初期値与えろってコンパイルエラーでるから、セカンダリコンストラクタに
str = "あいう" // これはsetter経由のプロパティアクセス
書いたんだけど、setter経由のプロパティアクセスだとsetterが>>658のようになってるって初期値実際与えられてないし・・

**デフォルトの名無しさん** · 2018/02/21(水) 19:38:04.92

>書いたんだけど、setter経由のプロパティアクセスだとsetterが>>658のようになってるって初期値実際与えられてないし・・
は
>書いたんだけど、setter経由のプロパティアクセスだとsetterが>>658のようになってるいじわるコードだと初期値実際与えられてないし・・
に修正

**デフォルトの名無しさん** · 2018/02/21(水) 19:44:04.71

そういうことね
確かにこれならsetterの部分でコンパイルエラー出て欲しい気がするな
帰ったらドキュメント舐め回してみるか

**デフォルトの名無しさん** · 2018/02/21(水) 22:17:43.95

>>658
lateinintつけないでコンパイル通ってしまうなら、Kotlinコンパイラのバグの可能性も...

**デフォルトの名無しさん** · 2018/02/21(水) 22:24:25.01

>>666は勘違いでした。申し訳ない。
>>658
多分あまりにも悪意に満ちた常人なら間違え内容のない契約プログラミング違反だから、
そこまでは面倒を見られないということかも。

**デフォルトの名無しさん** · 2018/02/21(水) 22:33:20.79

悪意の無い初心者がめちゃくちゃ書いてもちゃんと面倒見てくれるべきだと思う

**デフォルトの名無しさん** · 2018/02/21(水) 23:05:16.86

null安全の導入とともに変数は宣言時に初期値を与えなきゃいけなくなって、
ローカル変数は宣言時に与えなきゃいけないけど、インスタンス変数は宣言時または
コンストラクタ内で与えればOKなんだけど、
backingFieldを持つプロパティと相性悪かった？ってことかな。

backingFieldを持つプロパティはプロパティイニシャライザを与えるか、
コンストラクタ内でbackingFieldに直接初期化するという条件を付けくわえないとだめ？

field:str = "あいう" // コンストラクタ内でのみ使えるbakckingFieldにアクセスする専用構文の導入が必要　か
str = "あいう” // コンストラクタ内でのプロパティへの代入はsetterは経由しないとかの条件が必要

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

バグ相当だと思う

初期化(setter呼び出し)の有無は判定出来ているのだから
コンパイルエラーにするのが難しいなら
その直後にそのプロパティのBacking Fieldがnullだったら
KotlinNullPointerExceptionを投げる処理を暗黙的に追加すべき

**デフォルトの名無しさん** · 2018/02/22(木) 00:42:25.58

コンパイラor言語仕様のバグって意味ね

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

null安全の導入->非nullableのクラス型のデフォルト値なんてないから、変数は必ず初期化する
必要がある->(この再、nullable、非nullable関係なく全変数初期化するように)

未初期化の変数がコンパイラエラーにならないんて、これが言語仕様なら
仕様がクソだったってことだな(さすが、適当に作った言語ってことに)。
コンパイラのバグであることを祈ろう。

**666** · 2018/02/22(木) 06:49:37.65

>>658は、Test()でconstructor()が呼ばれないことについて
エラーも警告も出ないことも問題かもしれない。
>>672他
Javaで1回しか代入できないフィールドを作るのにsetterに渡された値を捨ててしまうことは
手法としては考えれられなくはないから、バグではなく仕様かも。
逆にチェックを厳しくし過ぎると出来そうなことができなくなる罠も出てくるから
完璧は無理かと。
Kotlin自体「実用的な」範囲でバランスをとったというコンセプトだし。

**666** · 2018/02/22(木) 06:57:22.88

>>673
の一つ目は勘違いでした。
Kotlinは便利だけど、いくつかの規則は言語仕様でなく契約に基づいていて
契約違反のコードは勘違いを起こさざるを得ないと言い訳する...orz

**デフォルトの名無しさん** · 2018/02/22(木) 07:31:42.26

C#でいいじゃん

**デフォルトの名無しさん** · 2018/02/22(木) 07:39:36.87

>>674
いや、この件は普通にコンパイラの仕様バグだと思うからissue上げて来なよ

**デフォルトの名無しさん** · 2018/02/22(木) 07:44:53.50

一回しか代入したくないならセッターの中にそういう処理を書けばいいだけだし、
非NullableなのにNullが入る状態でコンパイルできるのはどう考えてもバグでしょ

**デフォルトの名無しさん** · 2018/02/22(木) 07:45:17.47

>>673
そういう手法のときは内部フィールド側はNullableになっているべきじゃないかな
通常ケースの一つとしてnullがあるパターンなわけだから

private var strF: String? = null
var str: String get(){return strF ?: ""} set(value) { }

**デフォルトの名無しさん** · 2018/02/22(木) 09:29:54.25

setterを空にしたらバッキングフィールドへの代入は永遠にされないのでは？
外部からバッキングフィールドへの代入ってできないよね？
(getterで値を変更するカウンターみたいなやつは別として)。

**デフォルトの名無しさん** · 2018/02/22(木) 21:30:53.59

Nullableでないプロパティのsetterがnullの状態で呼ばれることがあるって考えるとなんか気持ち悪いな
俺の感覚だとsetterが呼ばれた時点でフィールドは初期化されていて欲しいしフィールドの初期化にsetterは使って欲しくない

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

JRubyよりはええんか？

**デフォルトの名無しさん** · 2018/02/23(金) 00:50:16.39

>>658の var str : String の部分を var str = "aaa" みたいに書くと var なのに str に何を代入しても
中身が"abc"のまま変化しないプロパティが完成w

**デフォルトの名無しさん** · 2018/02/23(金) 00:50:44.77

間違えた。"abc"じゃない"aaa"な。

**デフォルトの名無しさん** · 2018/02/23(金) 07:49:04.02

>>682
ワロタ
嫌な会社を辞めるときにテロとしてそういうコード残しておくイタズラとかできそう
それはそうとnullableじゃないのにnullになりうるセッターがコンパイル通るのはやっぱおかしいよな
そんなんする奴がいるのかって話ではあるが

**デフォルトの名無しさん** · 2018/02/23(金) 08:31:33.24

githubにあるkotlinのプロジェクトはissuesのリンクがないや
どこに報告すればいいんだ

**デフォルトの名無しさん** · 2018/02/23(金) 08:54:38.23

>>685
なぜREADMEを読まない…

**デフォルトの名無しさん** · 2018/02/23(金) 14:54:59.97

まとめ
https://paiza.io/projects/E8Wb5DZH7qOC-b5hcPSk3Q

**デフォルトの名無しさん** · 2018/02/23(金) 18:54:32.34

こりゃダメだ
C#使おっと

**デフォルトの名無しさん** · 2018/02/23(金) 19:22:20.80

>>687
えぇ…これ仕様通りなん？だとしたら糞じゃね？

**デフォルトの名無しさん** · 2018/02/23(金) 20:44:31.66

>>688
C#はこういうこと起きないの？
てか、そもそも同じような形式のプログラム作れるの？

**デフォルトの名無しさん** · 2018/02/23(金) 21:13:42.52

C#はそもそもnull安全じゃないから出てくること自体おかしい

**デフォルトの名無しさん** · 2018/02/23(金) 21:26:34.63

8.0ではoptinでnull安全にできるようになるんじゃなかったけ。まあ、でもmicrosoftはこんなポカしないと思うけど。

**デフォルトの名無しさん** · 2018/02/23(金) 22:05:57.26

オプティン…

**デフォルトの名無しさん** · 2018/02/23(金) 22:13:05.72

・セカンダリコンストラクタが存在する
・代入して初期化してる(ように見える)プライマリコンストラクタかセカンダリコンストラクタがある
この2つを満たすとコンパイル通っちゃうのかな
https://paiza.io/projects/78ZAW5fM_jNEyfhRPD5VbA

**デフォルトの名無しさん** · 2018/02/23(金) 22:28:48.21

>>694
こりゃコンパイラのバグ説が濃厚だな

**デフォルトの名無しさん** · 2018/02/23(金) 22:46:50.15

完全に趣味でSwift触り始めたんだけど、ことりんと似すぎてて脳の切り替えが大変

**デフォルトの名無しさん** · 2018/02/23(金) 23:32:19.57

setterがNOPだからでしょ
何もおかしくないと思うんだが

**デフォルトの名無しさん** · 2018/02/23(金) 23:51:24.69

>>697
Javaなら何もおかしくないけど、これはkotlinなんですよ

**デフォルトの名無しさん** · 2018/02/24(土) 00:23:17.37

あー、ごめんごめん、nullableじゃないのにってことね

**デフォルトの名無しさん** · 2018/02/24(土) 06:43:01.61

SwiftではOptionalよん

**デフォルトの名無しさん** · 2018/02/24(土) 06:47:11.68

そこら辺の名称も統一してくれたらよかったのに

**デフォルトの名無しさん** · 2018/02/24(土) 08:17:33.01

引数や戻り値の属性(アノテーション)としての出自でNullable (@Nullable)
型引数を持つデータ構造として出自でOptional (Optional<T>)

**デフォルトの名無しさん** · 2018/02/24(土) 08:21:38.91

だから何？

**デフォルトの名無しさん** · 2018/02/24(土) 08:32:56.79

単なる経緯にだからも何も無いんだけど

**デフォルトの名無しさん** · 2018/02/24(土) 09:18:53.65

Optionalではアンラップが必要で、Nullableでは不要

**デフォルトの名無しさん** · 2018/02/24(土) 15:32:03.48

つまりOptionalは神Nullableは糞

**デフォルトの名無しさん** · 2018/02/24(土) 15:33:06.32

間違えた逆だNullableは神Optionalは糞

**デフォルトの名無しさん** · 2018/02/24(土) 16:29:10.25

神と糞は種類が違うだろ

**デフォルトの名無しさん** · 2018/02/24(土) 16:55:50.73

Xamarin程の糞はない

**デフォルトの名無しさん** · 2018/02/24(土) 20:13:00.64

Kotlinではnullにならない型など存在しないのだ、がっはっは

**デフォルトの名無しさん** · 2018/02/24(土) 23:25:19.26

神は糞である。

**デフォルトの名無しさん** · 2018/02/25(日) 06:02:39.69

糞は紙で拭け

**デフォルトの名無しさん** · 2018/02/25(日) 10:33:42.84

Kotlinインアクションの尼評価低いなと思ったら理由が「難しい」ってw

**デフォルトの名無しさん** · 2018/02/25(日) 10:54:15.05

やっぱGroovy in Actionだろ、GradleはGrooovyなんだぜぇ

**デフォルトの名無しさん** · 2018/02/25(日) 11:44:58.69

こんな本が出てたんだな。

Androidアプリ開発の教科書
http://amzn.asia/59lxVwl

**デフォルトの名無しさん** · 2018/02/25(日) 11:46:33.02

あ、Kotlin で検索したら出てきた本だけど Kotlin とは限らないみたいだな。すまん。

**デフォルトの名無しさん** · 2018/02/25(日) 11:50:17.94

すまん。Kotlin の K の字も出てこないな。忘れてくれ。

**デフォルトの名無しさん** · 2018/02/25(日) 12:40:42.33

Kotlinイン・アクション、2017

Kotlinスタートブック -新しいAndroidプログラミング、長澤太郎、2016

せっかく太郎が、イン・アクションを参考にして、わかりやすく書いたのだから、
日本人は、太郎本を読んだ方がよい

**デフォルトの名無しさん** · 2018/02/25(日) 13:02:41.55

情報量はインアクションの方が多いから、わざわざ薄めた本を買う必要なんてないよ

**デフォルトの名無しさん** · 2018/02/25(日) 13:29:07.46

>>718
お前はスッキリをすすめてろよ

**デフォルトの名無しさん** · 2018/02/25(日) 14:16:36.00

Kotlin本といえば今のところインアクションとスタートブックの２択だと思うけど、
「難しい」って理由でレビュー評価下げるのはどうよ？と思ったんで、難しい以外に
インアクションで問題点ある？
バージョンが古いとか？

**デフォルトの名無しさん** · 2018/02/25(日) 14:31:03.18

※716
Androidの入門本なんてAndroid搭載機種の種類と同じくらい大量に出てるのになぜわざわざそれを貼ろうと思ったのか

**デフォルトの名無しさん** · 2018/02/25(日) 14:41:45.45

>>722
先に書いた通り、AmazonでKotlinで検索して出てきたため。

**デフォルトの名無しさん** · 2018/02/25(日) 15:09:27.72

電子書籍でレイアウト固定だと買う気しない

**デフォルトの名無しさん** · 2018/02/26(月) 08:03:23.98

知らんけどkotlinのandroid入門書なんてもう山ほど出てるんちゃうの？まだjavaばっかなの？

**デフォルトの名無しさん** · 2018/02/26(月) 08:23:30.09

まだ一冊しかないのでは？

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

そうなのか、意外と動き遅いんだな

**デフォルトの名無しさん** · 2018/02/26(月) 08:56:28.62

本で勉強する時代じゃないからね

**デフォルトの名無しさん** · 2018/02/26(月) 09:20:17.57

細切れ情報を探すのはやだな。レベルも方針もバラバラだし。
良書があるなら本がいい。

**デフォルトの名無しさん** · 2018/02/26(月) 09:34:26.29

まあ、AndroidでKotlin使うのは増え続けるだろうから何れ本も増えるだろう。

**デフォルトの名無しさん** · 2018/02/26(月) 09:43:22.22

本は中古やで何冊かあったよ、まだ高かったけど
正直Pythonは失敗だったと思う

**デフォルトの名無しさん** · 2018/02/26(月) 10:09:15.19

pythonは糞本で良書が埋もれちゃってる

**デフォルトの名無しさん** · 2018/02/26(月) 10:47:30.45

Null Objectパターン流行るといいなあ。

**デフォルトの名無しさん** · 2018/02/26(月) 13:51:07.53

>>732
流行った言語は自動的にそうなる。

**デフォルトの名無しさん** · 2018/02/26(月) 17:53:54.70

>>733
流行るも何もgof23パターンのうちの一つだぞ

**デフォルトの名無しさん** · 2018/02/26(月) 18:03:06.16

Null Objectはgof外でしょ

**デフォルトの名無しさん** · 2018/02/26(月) 18:15:26.27

>>735
すまぬ。
どうやらボケが始まったようだ…

**デフォルトの名無しさん** · 2018/02/26(月) 18:44:34.21

気にするな、禊としてXamarinのライセンス買ってこい

**デフォルトの名無しさん** · 2018/02/26(月) 18:51:59.91

買わない買わない

**デフォルトの名無しさん** · 2018/02/26(月) 19:46:08.16

>>721
本を読んだけどどっちもよかったよ。
ただ読み手のスキルで理解力に差があるからそこで評価が分かれてるのかも。

**デフォルトの名無しさん** · 2018/02/27(火) 10:02:27.46

IntelliJの変換機能使ってシコシコKotlinに変換してるけどstatic無いのがウザくなって来た
Swiftにはあるのにー

**デフォルトの名無しさん** · 2018/02/27(火) 12:16:20.20

>>741
コンパニオンは？

**デフォルトの名無しさん** · 2018/02/27(火) 18:56:17.20

自動変換使ったら普通にcompanion objectにならなかったっけ

**デフォルトの名無しさん** · 2018/02/27(火) 20:07:07.98

スーパーコンパニオンがいいです

**デフォルトの名無しさん** · 2018/02/27(火) 23:14:15.97

自動変換してもコンパニオンにならなかったから、シコシコ変えてる

**デフォルトの名無しさん** · 2018/02/27(火) 23:34:21.25

Android stuiosって糞重いのな
Xcodeの比じゃなかったわ

**デフォルトの名無しさん** · 2018/02/27(火) 23:39:03.53

Core i7、メモリ32GBだけど、コーディングに支障があるほど重いとは感じないかな

**デフォルトの名無しさん** · 2018/02/28(水) 00:05:50.05

ノート用のi5、8Gでもサクサク動くぞ

**デフォルトの名無しさん** · 2018/02/28(水) 01:54:55.83

基本xcodeの方が重くない？

**デフォルトの名無しさん** · 2018/02/28(水) 04:32:16.89

Android stuios...

**デフォルトの名無しさん** · 2018/02/28(水) 06:49:11.80

明らかにxcodeの方が重い

**デフォルトの名無しさん** · 2018/02/28(水) 06:51:00.64

あ、Android StudioじゃなくてAndroid stuiosの話なのか
それなら知らんわ

**デフォルトの名無しさん** · 2018/02/28(水) 07:13:17.29

VisualStudioはサクサク動くね

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

Android Studioはエミュレータの起動が激重

**デフォルトの名無しさん** · 2018/02/28(水) 08:51:39.92

お前のPCが糞なんだろ

**デフォルトの名無しさん** · 2018/02/28(水) 09:34:38.82

そういやエミュレータは遅いな。あれ速くならんもんかね？実機に繋いじゃうしかないか？

**デフォルトの名無しさん** · 2018/02/28(水) 11:19:49.30

そんなにおもいか？

**デフォルトの名無しさん** · 2018/02/28(水) 12:23:44.87

その部分はXcodeも糞重いからまあしゃあない

**デフォルトの名無しさん** · 2018/02/28(水) 13:05:00.32

お前の収入がまともなPCも買えないほど低いだけ

**デフォルトの名無しさん** · 2018/02/28(水) 15:32:06.67

Flutterが話題になってるけど、Dartなんだよなあ、、

**デフォルトの名無しさん** · 2018/02/28(水) 15:32:21.47

Kotlinならよかったのに