Kotlin 2

1デフォルトの名無しさん2017/11/01(水) 00:07:43.82ID:jxmKQQAl
JetBrainsが開発した期待の新言語Kotlinについて語りましょう
https://kotlinlang.org

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

629デフォルトの名無しさん2018/02/19(月) 17:37:58.45ID:jylwc8fn
ore,kore,sore

630デフォルトの名無しさん2018/02/19(月) 17:39:35.65ID:UjHZ69on
val 式の外側のthis = this

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

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

631デフォルトの名無しさん2018/02/19(月) 18:45:31.43ID:J+iGZU0/
class名.instanceはコトリンではつかえないのん?

632デフォルトの名無しさん2018/02/19(月) 22:24:58.24ID:9U/kf45x
>>631
objectで宣言したクラス(シングルトン)のclass名.INSTANCEのことでしょうか?

633デフォルトの名無しさん2018/02/19(月) 23:31:48.80ID:4xWfaW8A
エンクロージングインスタンスの話。
クラス名.thisの間違いだった。

634デフォルトの名無しさん2018/02/19(月) 23:50:04.20ID:bFR3uyhH
ラムダに束縛したいのはthisだけとは限らないしネストも有り得るので
クラス外の関数として分離した場合の引数名のイメージで変数名付けてる

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

635デフォルトの名無しさん2018/02/20(火) 06:41:06.84ID:qL04aTa6
>>634
真面目にいえば俺もこれ。
this_とかは仮に何かしらでもう一段ネストした時に詰む。

636デフォルトの名無しさん2018/02/20(火) 09:07:54.40ID:qXeXVbGF
ネストする時は、
this__
this___
this____
this_____

と、_を増やしてけば

637デフォルトの名無しさん2018/02/20(火) 10:02:20.87ID:I+nWo9FQ
よみづらい

638デフォルトの名無しさん2018/02/20(火) 10:02:36.87ID:pltRTpB+
>>636
フォントが違うと見え方が変わりそう

639デフォルトの名無しさん2018/02/20(火) 12:03:00.62ID:5NVGlXhy
>>636
天才かよ

640デフォルトの名無しさん2018/02/20(火) 12:57:02.91ID:DWBDu+Jk
ま、しかし、あまりにもネストが深くなるようならロジック考え直した方が良いかも

641デフォルトの名無しさん2018/02/20(火) 20:10:18.67ID:xSX01qXm
メソッド参照とか別クラスとか。

642デフォルトの名無しさん2018/02/20(火) 20:29:10.81ID:qXSQ9QV9
ネストは三段ぐらいまでにしといた方がいいだろうな。
その辺が迷宮の入り口だ。

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

643デフォルトの名無しさん2018/02/20(火) 20:35:32.22ID:qL04aTa6
せめて他のメソッドに切り出すくらいは最低でもやるべきだわな

644デフォルトの名無しさん2018/02/20(火) 22:17:03.69ID:/iBGk+pN
androidでデータバインディングしようとして
class Foo {
 @Bindable
 val bar get() = hoge.bar
}
とかできないの??・・・

645デフォルトの名無しさん2018/02/20(火) 22:18:25.44ID:/iBGk+pN
エラー内容はThis annotation is not applicable to target 'member property without
backingField or delegate'です。
どうしたらいいでしょかね

646デフォルトの名無しさん2018/02/20(火) 22:30:04.18ID:/iBGk+pN
Javaでは
class Foo {
 @Bindable
 String getBar() { hoge.getBar() }
}
で、hogeはFooのフィールド変数です。

647デフォルトの名無しさん2018/02/20(火) 23:05:50.58ID:/iBGk+pN
ごめんさい。解決しました。@get:Bindable

648デフォルトの名無しさん2018/02/21(水) 00:01:54.65ID:CION/kfn
また、アノテーションだけど。遅延初期化ではアノテーションつけれんの?しょぼーん。
@field:Transient
val lazyVal by lazy {}
だめか・・

649デフォルトの名無しさん2018/02/21(水) 14:48:51.57ID:aopUu534
いま触れてないけどkotlin-Nativeってどんな感じ?
ほとんどなんでもコンパイルかけれる?
見たところLLVM通すから行けそうだけど

650デフォルトの名無しさん2018/02/21(水) 15:35:13.89ID:HWbyxxJS
実用で使うのはまだ怖いけど、遊びで触る分にはちゃんと動くよ。
javaの標準パッケージが全く使えないから、jvmで動かす前提で作ってあるクラスだのライブラリだのが動かないという辛さはある。

651デフォルトの名無しさん2018/02/21(水) 16:03:44.92ID:wwQ+gY6z
javaのパッケージ使えないんならわざわざJVM言語使う価値なんかないわwさよなら〜

652デフォルトの名無しさん2018/02/21(水) 16:13:56.98ID:4d1xezjM
うん。はっきり言って現状ではこれを使うメリットが何一つ思い浮かばないよ俺も。

653デフォルトの名無しさん2018/02/21(水) 17:59:59.69ID:ftdNQJg9
地味にアップデートされてるからJBが飽きなければそのうち実用レベルになるかもねえ

654デフォルトの名無しさん2018/02/21(水) 18:05:11.04ID:2C7myRiq
それなりの標準ライブラリはあるんでしょ?まだないの?(ないわけないか。なければ Hello world も出せないもんな)

655デフォルトの名無しさん2018/02/21(水) 18:28:14.61ID:aopUu534
ありがとう。
なるほどまだ様子見しとくわ
Javaの標準パッケージ動かないの辛いね

656デフォルトの名無しさん2018/02/21(水) 18:37:05.98ID:KLOfXDKN
>>652
はいキチガイ

657デフォルトの名無しさん2018/02/21(水) 18:56:30.68ID:sG9Uh+s7
>>656がメリットを説明してくれる模様w

658デフォルトの名無しさん2018/02/21(水) 19:15:48.38ID:CION/kfn
この言語意味不明になってきた。
class Test {
 var str: String
  get() = field
  set(value) { }
 constructor() {
  str = "あいう"
 }
}
val t = Test()
普通にstrがnullになる

659デフォルトの名無しさん2018/02/21(水) 19:17:58.58ID:CION/kfn
セカンダリコンストラクタでstrのbakcingFieldにアクセスできないの??
 constructor() {
  str = "あいう" // これはsetter経由のプロパティアクセス
 }

660デフォルトの名無しさん2018/02/21(水) 19:21:36.71ID:ftdNQJg9
>>656
現状でこれ使ってハッピーなことがあるなら教えてくれw

661デフォルトの名無しさん2018/02/21(水) 19:23:37.72ID:ftdNQJg9
>>658-659
そのコードの意図がよく分からないんだけど、何がしたいの?ゆ

662デフォルトの名無しさん2018/02/21(水) 19:30:46.29ID:CION/kfn
>>661
意図はないけど、null安全とかいっておきながらkotlin側だけでnull入るコード書けるのまずいような気がする。
いや、プロパティの初期化方法がうざくて色々調べてたら気づいただけ。

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

664デフォルトの名無しさん2018/02/21(水) 19:38:04.92ID:CION/kfn
>書いたんだけど、setter経由のプロパティアクセスだとsetterが>>658のようになってるって初期値実際与えられてないし・・

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

665デフォルトの名無しさん2018/02/21(水) 19:44:04.71ID:ftdNQJg9
そういうことね
確かにこれならsetterの部分でコンパイルエラー出て欲しい気がするな
帰ったらドキュメント舐め回してみるか

666デフォルトの名無しさん2018/02/21(水) 22:17:43.95ID:mU+xwBkv
>>658
lateinintつけないでコンパイル通ってしまうなら、Kotlinコンパイラのバグの可能性も...

667デフォルトの名無しさん2018/02/21(水) 22:24:25.01ID:mU+xwBkv
>>666は勘違いでした。申し訳ない。
>>658
多分あまりにも悪意に満ちた常人なら間違え内容のない契約プログラミング違反だから、
そこまでは面倒を見られないということかも。

668デフォルトの名無しさん2018/02/21(水) 22:33:20.79ID:A2iqRMA5
悪意の無い初心者がめちゃくちゃ書いてもちゃんと面倒見てくれるべきだと思う

669デフォルトの名無しさん2018/02/21(水) 23:05:16.86ID:CION/kfn
null安全の導入とともに変数は宣言時に初期値を与えなきゃいけなくなって、
ローカル変数は宣言時に与えなきゃいけないけど、インスタンス変数は宣言時または
コンストラクタ内で与えればOKなんだけど、
backingFieldを持つプロパティと相性悪かった?ってことかな。

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

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

670デフォルトの名無しさん2018/02/22(木) 00:40:47.03ID:P3OwyHQx
バグ相当だと思う

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

671デフォルトの名無しさん2018/02/22(木) 00:42:25.58ID:P3OwyHQx
コンパイラor言語仕様のバグって意味ね

672デフォルトの名無しさん2018/02/22(木) 01:34:10.26ID:2g+h2XZc
null安全の導入->非nullableのクラス型のデフォルト値なんてないから、変数は必ず初期化する
必要がある->(この再、nullable、非nullable関係なく全変数初期化するように)

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

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

6746662018/02/22(木) 06:57:22.88ID:W5l1Fr+S
>>673
の一つ目は勘違いでした。
Kotlinは便利だけど、いくつかの規則は言語仕様でなく契約に基づいていて
契約違反のコードは勘違いを起こさざるを得ないと言い訳する...orz

675デフォルトの名無しさん2018/02/22(木) 07:31:42.26ID:tIZ7FSiP
C#でいいじゃん

676デフォルトの名無しさん2018/02/22(木) 07:39:36.87ID:HpXxCMc4
>>674
いや、この件は普通にコンパイラの仕様バグだと思うからissue上げて来なよ

677デフォルトの名無しさん2018/02/22(木) 07:44:53.50ID:HpXxCMc4
一回しか代入したくないならセッターの中にそういう処理を書けばいいだけだし、
非NullableなのにNullが入る状態でコンパイルできるのはどう考えてもバグでしょ

678デフォルトの名無しさん2018/02/22(木) 07:45:17.47ID:P3OwyHQx
>>673
そういう手法のときは内部フィールド側はNullableになっているべきじゃないかな
通常ケースの一つとしてnullがあるパターンなわけだから

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

679デフォルトの名無しさん2018/02/22(木) 09:29:54.25ID:tZO46ghF
setterを空にしたらバッキングフィールドへの代入は永遠にされないのでは?
外部からバッキングフィールドへの代入ってできないよね?
(getterで値を変更するカウンターみたいなやつは別として)。

新着レスの表示
レスを投稿する