Kotlin 2

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

Xamarinって確かライセンス買わないと使える機能に制限あるんじゃなかったっけ

**デフォルトの名無しさん** · 2018/02/13(火) 11:48:52.36

使った事がないのでわかりません

**デフォルトの名無しさん** · 2018/02/13(火) 12:50:25.21

そうか Java VMで動くC#があれば全て解決するのか

**デフォルトの名無しさん** · 2018/02/13(火) 14:45:21.02

>>537
なんでわざわざJVMで？

**デフォルトの名無しさん** · 2018/02/13(火) 16:28:11.56

C#自体あんまり好きじゃないから勘弁してくれ

**デフォルトの名無しさん** · 2018/02/13(火) 19:15:59.91

>>535
XamarinのライセンスはVisual Studioライセンスに統合されてる
Communityライセンスの条件内なら無料
そうでなければ年間サブスクリプションが必要（約6万円 / 年・開発者）

**デフォルトの名無しさん** · 2018/02/13(火) 20:59:24.53

安いなぁ

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

安いと感じるか高いと感じるかはあなたしだいです。

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

でここはKotlinスレでいいんだよな？

**デフォルトの名無しさん** · 2018/02/14(水) 00:51:14.52

Kotlin だって
いいじゃないか
JavaVM だもの

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

>>537
.NET上で動くJVMならあるけど(実用に耐えるとは言っていない)。
ttp://www.ikvm.net/index.html

**デフォルトの名無しさん** · 2018/02/14(水) 12:55:24.11

kotlinは好きだけどJVMがなぁ・・・
て思ってる人はかなり多いと思うよ

kotlin nativeに頑張ってもらって
さっさとJVMから足洗ってほしい

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

同意

**デフォルトの名無しさん** · 2018/02/14(水) 13:19:15.79

ぼきはJavaのライブラリ使うのでJVMでもいいれす(^p^）

**デフォルトの名無しさん** · 2018/02/14(水) 13:35:25.05

俺もとりあえずはJVMで良い。
気になるのはJavaScriptの方かな。

**デフォルトの名無しさん** · 2018/02/14(水) 17:38:51.85

Kotlinに移行しようかとしばらく触ってみたけど、C#の方が痒いところに手が届くいい言語だな、、、

**デフォルトの名無しさん** · 2018/02/14(水) 18:38:51.02

なんだかんだで膨大のJavaのライブラリとそれらのノウハウを使えるってのが大きいわな

**デフォルトの名無しさん** · 2018/02/14(水) 19:57:38.83

Javaの腐ったライブラリよりC#の洗練されたライブラリの方が有り難いんだけど

**デフォルトの名無しさん** · 2018/02/14(水) 20:14:34.75

>>551
>なんだかんだで膨大のJavaのライブラリとそのノウハウ
それを負の遺産という

**デフォルトの名無しさん** · 2018/02/14(水) 20:56:03.30

>>55
バッドノウハウは要らないのと神託社に抑えられいるのがイヤン

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

ほとんど借金なんだよなぁ
COBOLと同じ道辿ってる

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

イミフ

**デフォルトの名無しさん** · 2018/02/15(木) 13:04:38.64

JAVAの肩持つわけじゃないがCOBOLと同じ道は流石にないわ

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

COBOLとは全然状況違うよな
分散処理のフレームワークとかミドルとか活発に開発されてるし
言語としては最先端ではないかもしれないけど、逆に最先端の言語でも優れたプロダクトを生み出してないなら大して存在価値ないし

**デフォルトの名無しさん** · 2018/02/15(木) 18:44:01.31

これから終わるんだよ
kotlinとc#に駆逐される

**デフォルトの名無しさん** · 2018/02/15(木) 18:54:22.05

JavaVMの上でCOBOLが動くようになったりして･･･

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

一定の奴隷需要は残るだろうね

**デフォルトの名無しさん** · 2018/02/15(木) 19:36:21.03

これから終わると言われ続けて10年

**デフォルトの名無しさん** · 2018/02/15(木) 21:54:13.46

write once run anywhereとか言われてた頃が懐かしいな

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

>>560
いつだか覚えていないくらい昔にマジメにそれを開発しようとしてた会社があったような
COBOLしか書けないおじさんを救済するためだけの代物ですぐ頓挫したけど

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

まあでも確かにJava言語は使われなくなっていくだろうね。
うちもJavaで作ってるシステムの機能追加なんかはkotlinでやってるし、JVMで動かすのが要件な新規のプログラムももうほぼkotlinに移行してる。
スマホは知らんけどandroid開発はもうkotlinが多いのかな？

**デフォルトの名無しさん** · 2018/02/15(木) 23:12:11.62

ドロイド会議のアンケートでもkotlin使ってるひと多かったし

**デフォルトの名無しさん** · 2018/02/15(木) 23:59:58.64

Kotlinを推しつつもJavaはまだ現役だと考えている

しかしJava8でラムダが入ったときと
AndroidがJava8に対応したときは正直「余計なことしおって」と思ったな
Java6のままだったら今以上にKotlinが推されてただろうからｗ

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

しかしJavaのラムダはやりすぎだろって感じがした。

**デフォルトの名無しさん** · 2018/02/16(金) 05:43:13.28

確かに
レガシーJavaおじさんと現代人Kotlin使いで棲みわけた方が平和だったかもしれないね

**デフォルトの名無しさん** · 2018/02/16(金) 06:37:35.95

kotlinでandroidの説明してるところなんか全然ない
先進的な一部が勝手に使い始めてるだけで普及の段階ではない、いつもながら日本は遅れてる

**デフォルトの名無しさん** · 2018/02/16(金) 06:49:21.30

全然ないことはないだろ

**デフォルトの名無しさん** · 2018/02/16(金) 07:11:23.90

(僕の周りでは)全然ない
(国内では)全然ない

**デフォルトの名無しさん** · 2018/02/16(金) 07:17:40.02

最近ネットに出て来るandroid周りのサンプルはほぼkotlinじゃない？

**デフォルトの名無しさん** · 2018/02/16(金) 09:05:39.78

kotlinの実務経験ないやつは失業ざまあｗｗｗ

**デフォルトの名無しさん** · 2018/02/16(金) 09:19:32.40

実務経験って、そもそも実務で使われてる所がまだ少なかろう。

**デフォルトの名無しさん** · 2018/02/16(金) 10:41:09.40

実際DroidKaigiのセッションスライドのコードはほぼKotlinだったし、実務もKotilnである割合はかなり増えてるでしょ。
自分も実務ではもう1年くらい使ってるし。

**デフォルトの名無しさん** · 2018/02/16(金) 10:58:35.59

そりゃAndroidだから増えてて当然な感じするが、世の中にはAndroidしかないわけではないからなあ。

**デフォルトの名無しさん** · 2018/02/16(金) 11:06:50.68

俺は逆にandroidまったくやらんけどkotlinめっちゃ使ってるよ
ローカルのプログラムでもサーバーサイドでも

まだこういうのは少数派だろうけど

**デフォルトの名無しさん** · 2018/02/16(金) 12:46:25.84

ああ。俺は趣味では使うよ。というか学習中なので敢えて使う感じ。Kotlinだとどう書けるかを調べながら書いてる感じ。

**デフォルトの名無しさん** · 2018/02/16(金) 12:47:35.63

ながら勉強？

**デフォルトの名無しさん** · 2018/02/16(金) 12:58:29.56

ながらというか、CやPerlなら仕事で何十年も使ってて間が働くからどう書くかはすぐ想像できる(Javaも趣味で20年ぐらいやってるのでなんとなくわかる)んだが、
Kotlinはそれと似たようにも書けるしKotlinならではの書き方もできるわけで、その辺のKpylin的な書き方を学習してる感じ。

**デフォルトの名無しさん** · 2018/02/16(金) 12:59:00.48

間がじゃない、勘がだ。

**デフォルトの名無しさん** · 2018/02/16(金) 13:01:00.94

うう。やはりスマホだと変なタイプミス増えるな。orz

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

くぴりんｗ

**デフォルトの名無しさん** · 2018/02/16(金) 13:05:28.66

どうせお前らrxもMVVMもfluxも分からないんだろ
失業ざまああｗｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2018/02/16(金) 15:00:09.56

どこかで聞いたことがあるようなないような・・・

**デフォルトの名無しさん** · 2018/02/16(金) 18:08:43.61

>>583
タイプミスじゃなくて誤変換
フリックは関係ない、注意力が欠けてるだけ

**デフォルトの名無しさん** · 2018/02/16(金) 19:12:39.30

>>585
rxとmvvmはわかる
fluxがわからないから3行で説明して

**デフォルトの名無しさん** · 2018/02/16(金) 19:50:26.64

>>588
片
方
向

**デフォルトの名無しさん** · 2018/02/16(金) 20:40:30.87

俺
も
知らない

**デフォルトの名無しさん** · 2018/02/16(金) 21:50:37.65

車輪の
再発明に
名前を付けた

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

モルゲッソヨ

**デフォルトの名無しさん** · 2018/02/16(金) 22:11:32.26

今分かったんですけど、プライマリコンストラクタ宣言せずに
セカンダリコンストラクタって宣言できるんですね。

プライマリコンストラクタの主な用途ってコンストラクタのパラメータの宣言とプロパティの宣言を
一緒にできるぐらいですか？？用途は。
class Test(val p1: String)とか

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

>>593
中身が空っぽなだけで、プライマリコンストラクタは常にあるよ
https://ideone.com/tSGMPY

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

基本は省略表記なだけ
https://ideone.com/3Uc2dJ

**デフォルトの名無しさん** · 2018/02/17(土) 00:19:37.32

>>594
でも、空のプライマリコンストラクタを明示的に宣言するのと省略するのでは厳密には同一ではないですよね？？

だから、言葉の定義の問題にもなっちゃうけど、initブロックはinitブロックであってプライマリコンストラクタと同一視
しない方がいいとか。プライマリコンストラクタはあくまでclass Test(val p1: String)のval p1: String部分だけで、
プライマリコンストラクタはボディは持てない。
初期化はinitブロックで行うとか？

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

https://kotlinlang.org/docs/reference/classes.html
正式な言語仕様書とかないんでしったけ？？
JavaとかC#はしっかりした言語仕様書みたいのあって言葉もしっかり定義されてると
思いますが、kotlinはそういうのないとか・・

**デフォルトの名無しさん** · 2018/02/17(土) 00:37:46.91

Note that code in initializer blocks effectively becomes part of the primary constructor.
Delegation to the primary constructor happens as the first statement of a secondary constructor, so the code in all initializer blocks is executed before the secondary constructor body
まぁ、ここにはプライマリコンストラクタの一部になるって書いてあるね。

**デフォルトの名無しさん** · 2018/02/17(土) 00:43:30.54

>>596
そうね暗黙の場合と違いあるから省略という表現は不正確だったごめん

セカンダリコンストラクタが無い場合、暗黙のプライマリコンストラクタはpublicになる
セカンダリコンストラクタが有る場合、暗黙のプライマリコンストラクタは未初期化メンバを残せる

**デフォルトの名無しさん** · 2018/02/17(土) 01:07:01.46

>>597
明らかにまだ未完成だけどこれだと思う
http://jetbrains.github.io/kotlin-spec/

**デフォルトの名無しさん** · 2018/02/17(土) 09:11:07.08

Kotlin使いがJava使いにマウント取ってる様を見てまたこの繰り返しかと思いそっ閉じ

**デフォルトの名無しさん** · 2018/02/17(土) 11:37:12.55

マウント取ってるように見える？そりゃなんていうか、劣等感強すぎでは？
てか一々そんなこと考えてないで自分でも使えばいいじゃん。禁止されているわけでもなし。
Java が使える状態になったことのある人が Kotlin 使えるようになれないわけがないと思うが。

**デフォルトの名無しさん** · 2018/02/17(土) 19:20:37.06

ていうかkotlin使いって99%Java使いも兼ねてるだろうからマウントとるも何もないのでは

**デフォルトの名無しさん** · 2018/02/17(土) 22:06:51.34

今使ってる人はそもそもJavaできるからな
より使いやすくても、対立構造にはならないよな

**デフォルトの名無しさん** · 2018/02/18(日) 01:22:27.54

>>557
モバイル開発は違うかもだが、業務系は極端に言っちまうとjava要員集めるっつたら使い捨て兵隊集めだよ。

**デフォルトの名無しさん** · 2018/02/18(日) 11:33:46.48

そんな自分の知ってる世界だけの狭い話をされても

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

Kotlin, RxJava, MVVMは基本的な必須スキルだからな
未だに実務経験ないやつは失業確定ざまああｗｗｗｗｗｗｗ

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

>>605
兵隊だなんてでたらめ書くなよ
兵隊じゃなくて奴隷だぞ

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

Android系の技術スレは失業だの兵隊だの低いところでマウント争ってるんだな。稼いでるやついなそう。

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

そういやKotlinはまだ求人数は少ないけど給与は良いって調査結果があったな
中途半端だと仕事にありつけないかもしれないな

**デフォルトの名無しさん** · 2018/02/18(日) 14:56:03.30

しかしKotlinってKotlinらしくない従来のJavaっぽい書き方をしても動いてしまうからな。金を多く払う意味があまりないかも知れないぞ。

**デフォルトの名無しさん** · 2018/02/18(日) 16:12:24.98

Kotlinで単価が高いのは、チームが今後Kotlinでやってけるように導入の面倒見れる人だよ
>>611が言ってるレベルの奴なんてそもそも高い単価で雇われないから

**デフォルトの名無しさん** · 2018/02/18(日) 16:20:57.25

面倒みなきゃならんほどのものじゃないでしょ
プログラム初心者じゃあるまいし

**デフォルトの名無しさん** · 2018/02/18(日) 16:37:41.33

>>613
お前の周辺状況について述べてるわけじゃないことぐらい理解して

**デフォルトの名無しさん** · 2018/02/18(日) 16:51:37.36

>>612
雇う側がそれを見抜ければ良いんだろうけどね。

**デフォルトの名無しさん** · 2018/02/18(日) 17:24:17.84

>>614
確認だけど職業としてプログラマやってる人たちの話って前提だよね？
小学校のプログラムの授業とかじゃなくて

**デフォルトの名無しさん** · 2018/02/18(日) 19:36:30.68

>>616
もういいよめんどくさい
じゃあKotlinできればそのレベルに関わらず誰でも単価高いってことでええわ

**デフォルトの名無しさん** · 2018/02/18(日) 22:46:31.63

ラムダ式から式の外側のthisを参照するにはどうすればいいでしょうか？現状、
val this_ = this
async {
　this_
}
とかしてますけど、これ以外方法ない？

**デフォルトの名無しさん** · 2018/02/19(月) 00:54:19.29

>>618
無いことはないけど俺もそうしてるよ
class A {
　　fun f(){
　　　　async {
　　　　　　this@A
　　　　}
　　}
}
https://kotlinlang.org/docs/reference/this-expressions.html

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

>>618
結局それが1番手っ取り早いと思うけど、this_っていう変数名は気持ち悪いから嫌

**デフォルトの名無しさん** · 2018/02/19(月) 11:29:23.81

言っとくけどselfもダサいよ

**デフォルトの名無しさん** · 2018/02/19(月) 11:44:10.96

そうじゃねえだろ
それを言うなら、self_ もダサい

**デフォルトの名無しさん** · 2018/02/19(月) 12:18:18.12

やっぱ thiz だよね

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

どう書いても最適化されて同じコードになったりして･･･

**デフォルトの名無しさん** · 2018/02/19(月) 16:13:32.25

俺なら一目で何だか分かる名前にする

**デフォルトの名無しさん** · 2018/02/19(月) 17:29:10.39

例えば？

**デフォルトの名無しさん** · 2018/02/19(月) 17:33:59.71

>>619
ありがとうござます。this@hogeを使う事にしました

**デフォルトの名無しさん** · 2018/02/19(月) 17:36:07.64

>>626
val unko = this

**デフォルトの名無しさん** · 2018/02/19(月) 17:37:58.45

ore,kore,sore

**デフォルトの名無しさん** · 2018/02/19(月) 17:39:35.65

val 式の外側のthis = this

async {
式の外側のthis.method()
}

これが1番わかりやすいな

**デフォルトの名無しさん** · 2018/02/19(月) 18:45:31.43

class名.instanceはコトリンではつかえないのん？

**デフォルトの名無しさん** · 2018/02/19(月) 22:24:58.24

>>631
objectで宣言したクラス(シングルトン)のclass名.INSTANCEのことでしょうか?

**デフォルトの名無しさん** · 2018/02/19(月) 23:31:48.80

エンクロージングインスタンスの話。
クラス名.thisの間違いだった。

**デフォルトの名無しさん** · 2018/02/19(月) 23:50:04.20

ラムダに束縛したいのはthisだけとは限らないしネストも有り得るので
クラス外の関数として分離した場合の引数名のイメージで変数名付けてる

val view = this
val cal = activeCalculator
async {
　　cal.recalc()
　　transaction {
　　　　val tran = this
　　　　check(cal, tran)
　　}
　　view.notifyUpdate()
}

**デフォルトの名無しさん** · 2018/02/20(火) 06:41:06.84

>>634
真面目にいえば俺もこれ。
this_とかは仮に何かしらでもう一段ネストした時に詰む。

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

ネストする時は、
this__
this___
this____
this_____

と、_を増やしてけば

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

よみづらい

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

>>636
フォントが違うと見え方が変わりそう

**デフォルトの名無しさん** · 2018/02/20(火) 12:03:00.62

>>636
天才かよ

**デフォルトの名無しさん** · 2018/02/20(火) 12:57:02.91

ま、しかし、あまりにもネストが深くなるようならロジック考え直した方が良いかも

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

メソッド参照とか別クラスとか。

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

ネストは三段ぐらいまでにしといた方がいいだろうな。
その辺が迷宮の入り口だ。

Cのポインタとかも同じ。3段以上先には魔物が住んでいる。

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

せめて他のメソッドに切り出すくらいは最低でもやるべきだわな

**デフォルトの名無しさん** · 2018/02/20(火) 22:17:03.69

androidでデータバインディングしようとして
class Foo {
　@Bindable
　val bar get() = hoge.bar
}
とかできないの？？・・・

**デフォルトの名無しさん** · 2018/02/20(火) 22:18:25.44

エラー内容はThis annotation is not applicable to target 'member property without
backingField or delegate'です。
どうしたらいいでしょかね

**デフォルトの名無しさん** · 2018/02/20(火) 22:30:04.18

Javaでは
class Foo {
　@Bindable
　String getBar() { hoge.getBar() }
}
で、hogeはFooのフィールド変数です。

**デフォルトの名無しさん** · 2018/02/20(火) 23:05:50.58

ごめんさい。解決しました。@get:Bindable

**デフォルトの名無しさん** · 2018/02/21(水) 00:01:54.65

また、アノテーションだけど。遅延初期化ではアノテーションつけれんの？しょぼーん。
@field:Transient
val lazyVal by lazy {}
だめか・・

**デフォルトの名無しさん** · 2018/02/21(水) 14:48:51.57

いま触れてないけどkotlin-Nativeってどんな感じ？
ほとんどなんでもコンパイルかけれる？
見たところLLVM通すから行けそうだけど

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

実用で使うのはまだ怖いけど、遊びで触る分にはちゃんと動くよ。
javaの標準パッケージが全く使えないから、jvmで動かす前提で作ってあるクラスだのライブラリだのが動かないという辛さはある。

**デフォルトの名無しさん** · 2018/02/21(水) 16:03:44.92

javaのパッケージ使えないんならわざわざJVM言語使う価値なんかないわｗさよなら～

**デフォルトの名無しさん** · 2018/02/21(水) 16:13:56.98

うん。はっきり言って現状ではこれを使うメリットが何一つ思い浮かばないよ俺も。

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

地味にアップデートされてるからJBが飽きなければそのうち実用レベルになるかもねえ

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

それなりの標準ライブラリはあるんでしょ？まだないの？(ないわけないか。なければ Hello world も出せないもんな)

**デフォルトの名無しさん** · 2018/02/21(水) 18:28:14.61

ありがとう。
なるほどまだ様子見しとくわ
Javaの標準パッケージ動かないの辛いね

**デフォルトの名無しさん** · 2018/02/21(水) 18:37:05.98

>>652
はいキチガイ

**デフォルトの名無しさん** · 2018/02/21(水) 18:56:30.68

>>656がメリットを説明してくれる模様ｗ

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

この言語意味不明になってきた。
class Test {
　var str: String
　　get() = field
　　set(value) { }
　constructor() {
　　str = "あいう"
　}
}
val t = Test()
普通にstrがnullになる

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

セカンダリコンストラクタでstrのbakcingFieldにアクセスできないの？？
　constructor() {
　　str = "あいう" // これはsetter経由のプロパティアクセス
　}

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

>>656
現状でこれ使ってハッピーなことがあるなら教えてくれw

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

>>658-659
そのコードの意図がよく分からないんだけど、何がしたいの？ゆ

**デフォルトの名無しさん** · 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
流行った言語は自動的にそうなる。