Kotlin使いがJava使いにマウント取ってる様を見てまたこの繰り返しかと思いそっ閉じ
マウント取ってるように見える？そりゃなんていうか、劣等感強すぎでは？
てか一々そんなこと考えてないで自分でも使えばいいじゃん。禁止されているわけでもなし。
Java が使える状態になったことのある人が Kotlin 使えるようになれないわけがないと思うが。
ていうかkotlin使いって99%Java使いも兼ねてるだろうからマウントとるも何もないのでは
今使ってる人はそもそもJavaできるからな
より使いやすくても、対立構造にはならないよな
>>557
モバイル開発は違うかもだが、業務系は極端に言っちまうとjava要員集めるっつたら使い捨て兵隊集めだよ。 Kotlin, RxJava, MVVMは基本的な必須スキルだからな
未だに実務経験ないやつは失業確定ざまああｗｗｗｗｗｗｗ
>>605
兵隊だなんてでたらめ書くなよ
兵隊じゃなくて奴隷だぞ Android系の技術スレは失業だの兵隊だの低いところでマウント争ってるんだな。稼いでるやついなそう。
そういやKotlinはまだ求人数は少ないけど給与は良いって調査結果があったな
中途半端だと仕事にありつけないかもしれないな
しかしKotlinってKotlinらしくない従来のJavaっぽい書き方をしても動いてしまうからな。金を多く払う意味があまりないかも知れないぞ。
Kotlinで単価が高いのは、チームが今後Kotlinでやってけるように導入の面倒見れる人だよ
>>611が言ってるレベルの奴なんてそもそも高い単価で雇われないから 面倒みなきゃならんほどのものじゃないでしょ
プログラム初心者じゃあるまいし
>>613
お前の周辺状況について述べてるわけじゃないことぐらい理解して >>612
雇う側がそれを見抜ければ良いんだろうけどね。 >>614
確認だけど職業としてプログラマやってる人たちの話って前提だよね？
小学校のプログラムの授業とかじゃなくて >>616
もういいよめんどくさい
じゃあKotlinできればそのレベルに関わらず誰でも単価高いってことでええわ ラムダ式から式の外側のthisを参照するにはどうすればいいでしょうか？現状、
val this_ = this
async {
this_
}
とかしてますけど、これ以外方法ない？
>>618
結局それが1番手っ取り早いと思うけど、this_っていう変数名は気持ち悪いから嫌 そうじゃねえだろ
それを言うなら、self_ もダサい
どう書いても最適化されて同じコードになったりして･･･
>>619
ありがとうござます。this@hogeを使う事にしました val 式の外側のthis = this
async {
式の外側のthis.method()
}
これが1番わかりやすいな
class名.instanceはコトリンではつかえないのん？
>>631
objectで宣言したクラス(シングルトン)のclass名.INSTANCEのことでしょうか? エンクロージングインスタンスの話。
クラス名.thisの間違いだった。
ラムダに束縛したいのはthisだけとは限らないしネストも有り得るので
クラス外の関数として分離した場合の引数名のイメージで変数名付けてる
val view = this
val cal = activeCalculator
async {
cal.recalc()
transaction {
val tran = this
check(cal, tran)
}
view.notifyUpdate()
}
>>634
真面目にいえば俺もこれ。
this_とかは仮に何かしらでもう一段ネストした時に詰む。 ネストする時は、
this__
this___
this____
this_____
と、_を増やしてけば
ま、しかし、あまりにもネストが深くなるようならロジック考え直した方が良いかも
ネストは三段ぐらいまでにしといた方がいいだろうな。
その辺が迷宮の入り口だ。
Cのポインタとかも同じ。3段以上先には魔物が住んでいる。
せめて他のメソッドに切り出すくらいは最低でもやるべきだわな
androidでデータバインディングしようとして
class Foo {
@Bindable
val bar get() = hoge.bar
}
とかできないの？？・・・
エラー内容はThis annotation is not applicable to target 'member property without
backingField or delegate'です。
どうしたらいいでしょかね
Javaでは
class Foo {
@Bindable
String getBar() { hoge.getBar() }
}
で、hogeはFooのフィールド変数です。
ごめんさい。解決しました。@get:Bindable
また、アノテーションだけど。遅延初期化ではアノテーションつけれんの？しょぼーん。
@field:Transient
val lazyVal by lazy {}
だめか・・
いま触れてないけどkotlin-Nativeってどんな感じ？
ほとんどなんでもコンパイルかけれる？
見たところLLVM通すから行けそうだけど
実用で使うのはまだ怖いけど、遊びで触る分にはちゃんと動くよ。
javaの標準パッケージが全く使えないから、jvmで動かす前提で作ってあるクラスだのライブラリだのが動かないという辛さはある。
javaのパッケージ使えないんならわざわざJVM言語使う価値なんかないわｗさよなら〜
うん。はっきり言って現状ではこれを使うメリットが何一つ思い浮かばないよ俺も。
地味にアップデートされてるからJBが飽きなければそのうち実用レベルになるかもねえ
それなりの標準ライブラリはあるんでしょ？まだないの？(ないわけないか。なければ Hello world も出せないもんな)
ありがとう。
なるほどまだ様子見しとくわ
Javaの標準パッケージ動かないの辛いね
この言語意味不明になってきた。
class Test {
var str: String
get() = field
set(value) { }
constructor() {
str = "あいう"
}
}
val t = Test()
普通にstrがnullになる
セカンダリコンストラクタでstrのbakcingFieldにアクセスできないの？？
constructor() {
str = "あいう" // これはsetter経由のプロパティアクセス
}
>>656
現状でこれ使ってハッピーなことがあるなら教えてくれw >>661
意図はないけど、null安全とかいっておきながらkotlin側だけでnull入るコード書けるのまずいような気がする。
いや、プロパティの初期化方法がうざくて色々調べてたら気づいただけ。 プロパティ宣言すると初期値与えろってうるさいんだけど、うるさいのはいいんだけど初期値の与え方が
val str: String = プロパティイニシャライザ
プロパティイニシャライザ以外、bakcingFieldに直接与える方法ないの？？
>>659だって、初期値与えろってコンパイルエラーでるから、セカンダリコンストラクタに
str = "あいう" // これはsetter経由のプロパティアクセス
書いたんだけど、setter経由のプロパティアクセスだとsetterが>>658のようになってるって初期値実際与えられてないし・・ >書いたんだけど、setter経由のプロパティアクセスだとsetterが>>658のようになってるって初期値実際与えられてないし・・
は
>書いたんだけど、setter経由のプロパティアクセスだとsetterが>>658のようになってるいじわるコードだと初期値実際与えられてないし・・
に修正 そういうことね
確かにこれならsetterの部分でコンパイルエラー出て欲しい気がするな
帰ったらドキュメント舐め回してみるか
>>658
lateinintつけないでコンパイル通ってしまうなら、Kotlinコンパイラのバグの可能性も... >>666は勘違いでした。申し訳ない。
>>658
多分あまりにも悪意に満ちた常人なら間違え内容のない契約プログラミング違反だから、
そこまでは面倒を見られないということかも。 悪意の無い初心者がめちゃくちゃ書いてもちゃんと面倒見てくれるべきだと思う
null安全の導入とともに変数は宣言時に初期値を与えなきゃいけなくなって、
ローカル変数は宣言時に与えなきゃいけないけど、インスタンス変数は宣言時または
コンストラクタ内で与えればOKなんだけど、
backingFieldを持つプロパティと相性悪かった？ってことかな。
backingFieldを持つプロパティはプロパティイニシャライザを与えるか、
コンストラクタ内でbackingFieldに直接初期化するという条件を付けくわえないとだめ？
field:str = "あいう" // コンストラクタ内でのみ使えるbakckingFieldにアクセスする専用構文の導入が必要 か
str = "あいう” // コンストラクタ内でのプロパティへの代入はsetterは経由しないとかの条件が必要
バグ相当だと思う
初期化(setter呼び出し)の有無は判定出来ているのだから
コンパイルエラーにするのが難しいなら
その直後にそのプロパティのBacking Fieldがnullだったら
KotlinNullPointerExceptionを投げる処理を暗黙的に追加すべき
null安全の導入->非nullableのクラス型のデフォルト値なんてないから、変数は必ず初期化する
必要がある->(この再、nullable、非nullable関係なく全変数初期化するように)
未初期化の変数がコンパイラエラーにならないんて、これが言語仕様なら
仕様がクソだったってことだな(さすが、適当に作った言語ってことに)。
コンパイラのバグであることを祈ろう。
>>658は、Test()でconstructor()が呼ばれないことについて
エラーも警告も出ないことも問題かもしれない。
>>672他
Javaで1回しか代入できないフィールドを作るのにsetterに渡された値を捨ててしまうことは
手法としては考えれられなくはないから、バグではなく仕様かも。
逆にチェックを厳しくし過ぎると出来そうなことができなくなる罠も出てくるから
完璧は無理かと。
Kotlin自体「実用的な」範囲でバランスをとったというコンセプトだし。 >>673
の一つ目は勘違いでした。
Kotlinは便利だけど、いくつかの規則は言語仕様でなく契約に基づいていて
契約違反のコードは勘違いを起こさざるを得ないと言い訳する...orz >>674
いや、この件は普通にコンパイラの仕様バグだと思うからissue上げて来なよ 一回しか代入したくないならセッターの中にそういう処理を書けばいいだけだし、
非NullableなのにNullが入る状態でコンパイルできるのはどう考えてもバグでしょ
>>673
そういう手法のときは内部フィールド側はNullableになっているべきじゃないかな
通常ケースの一つとしてnullがあるパターンなわけだから
private var strF: String? = null
var str: String get(){return strF ?: ""} set(value) { } setterを空にしたらバッキングフィールドへの代入は永遠にされないのでは？
外部からバッキングフィールドへの代入ってできないよね？
(getterで値を変更するカウンターみたいなやつは別として)。
Nullableでないプロパティのsetterがnullの状態で呼ばれることがあるって考えるとなんか気持ち悪いな
俺の感覚だとsetterが呼ばれた時点でフィールドは初期化されていて欲しいしフィールドの初期化にsetterは使って欲しくない
>>658の var str : String の部分を var str = "aaa" みたいに書くと var なのに str に何を代入しても
中身が"abc"のまま変化しないプロパティが完成w >>682
ワロタ
嫌な会社を辞めるときにテロとしてそういうコード残しておくイタズラとかできそう
それはそうとnullableじゃないのにnullになりうるセッターがコンパイル通るのはやっぱおかしいよな
そんなんする奴がいるのかって話ではあるが githubにあるkotlinのプロジェクトはissuesのリンクがないや
どこに報告すればいいんだ
>>687
えぇ…これ仕様通りなん？だとしたら糞じゃね？ >>688
C#はこういうこと起きないの？
てか、そもそも同じような形式のプログラム作れるの？ C#はそもそもnull安全じゃないから出てくること自体おかしい
8.0ではoptinでnull安全にできるようになるんじゃなかったけ。まあ、でもmicrosoftはこんなポカしないと思うけど。
完全に趣味でSwift触り始めたんだけど、ことりんと似すぎてて脳の切り替えが大変
setterがNOPだからでしょ
何もおかしくないと思うんだが
>>697
Javaなら何もおかしくないけど、これはkotlinなんですよ あー、ごめんごめん、nullableじゃないのにってことね
引数や戻り値の属性(アノテーション)としての出自でNullable (@Nullable)
型引数を持つデータ構造として出自でOptional (Optional<T>)
Optionalではアンラップが必要で、Nullableでは不要
間違えた逆だNullableは神Optionalは糞
Kotlinではnullにならない型など存在しないのだ、がっはっは
Kotlinインアクションの尼評価低いなと思ったら理由が「難しい」ってw
やっぱGroovy in Actionだろ、GradleはGrooovyなんだぜぇ
あ、Kotlin で検索したら出てきた本だけど Kotlin とは限らないみたいだな。すまん。
すまん。Kotlin の K の字も出てこないな。忘れてくれ。
Kotlinイン・アクション、2017
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016
せっかく太郎が、イン・アクションを参考にして、わかりやすく書いたのだから、
日本人は、太郎本を読んだ方がよい
情報量はインアクションの方が多いから、わざわざ薄めた本を買う必要なんてないよ
Kotlin本といえば今のところインアクションとスタートブックの２択だと思うけど、
「難しい」って理由でレビュー評価下げるのはどうよ？と思ったんで、難しい以外に
インアクションで問題点ある？
バージョンが古いとか？
※716
Androidの入門本なんてAndroid搭載機種の種類と同じくらい大量に出てるのになぜわざわざそれを貼ろうと思ったのか
>>722
先に書いた通り、AmazonでKotlinで検索して出てきたため。 知らんけどkotlinのandroid入門書なんてもう山ほど出てるんちゃうの？まだjavaばっかなの？
細切れ情報を探すのはやだな。レベルも方針もバラバラだし。
良書があるなら本がいい。
まあ、AndroidでKotlin使うのは増え続けるだろうから何れ本も増えるだろう。
本は中古やで何冊かあったよ、まだ高かったけど
正直Pythonは失敗だったと思う
>>733
流行るも何もgof23パターンのうちの一つだぞ >>735
すまぬ。
どうやらボケが始まったようだ… 気にするな、禊としてXamarinのライセンス買ってこい
>>721
本を読んだけどどっちもよかったよ。
ただ読み手のスキルで理解力に差があるからそこで評価が分かれてるのかも。 IntelliJの変換機能使ってシコシコKotlinに変換してるけどstatic無いのがウザくなって来た
Swiftにはあるのにー
自動変換使ったら普通にcompanion objectにならなかったっけ
自動変換してもコンパニオンにならなかったから、シコシコ変えてる
Android stuiosって糞重いのな
Xcodeの比じゃなかったわ
Core i7、メモリ32GBだけど、コーディングに支障があるほど重いとは感じないかな
あ、Android StudioじゃなくてAndroid stuiosの話なのか
それなら知らんわ
Android Studioはエミュレータの起動が激重
そういやエミュレータは遅いな。あれ速くならんもんかね？実機に繋いじゃうしかないか？
Flutterが話題になってるけど、Dartなんだよなあ、、
IntelliJファミリーのIDEが不自然に重い時はプラグインを疑った方が良い
もしくは単純にindexingか何かをしてるだけか
とりあえず2013年モデルでメモリ8GBのMBPでもサクサク動く
googleさんの本命はkotlinじゃなくてflutterのDartだったってこと?
いや、あの会社がプログラミング言語を開発するのは趣味みたいなもんだから。
有名どころだけでもGASとgoとDartとあるからな
統一しろや
なんかgoogleって統一感無いよなー。
dart捨てたと思ってたのに、このタイミングで復活させるとかさ。ならchromeに予定通りvm載せろや
>>773
それが望ましいな。まぁ、Flutter+Dartが成功したらchromeにもDartVM搭載復活とかあるかもね。
それで、JavaScript絶滅に追いやってほしいわ。
今どきの言語ならなんえり好みしないからフロントエンドからJavaScriptを絶滅に追いやってほしい。 未だにKotlinの実務経験のないやつは完全失業ざまあｗｗｗ
つか、あれ、ラムダ式の中で値返すときretrunとかキーワードつけないのかー
ふーんって思ったけど、制御までreturnするんじゃないのか・・
{
if (条件式) 値1
その他の文
値2
}
で、if文の条件式が真の時、値1が返ってreturnするのかと思ったらその後も実行されるのか・・
あれ、どうやって値返すんだよん。if else使いたくないんだけど。
>>775
jsを、撲滅ってESの最新仕様追いかけなよ。
悪くないから コンパイルエラーがでるからそこらへん適当にやっててもなんとかなったけどww。
真面目に考えるとどうなってんだこれww
今までコンパイルエラーが消えるように適当に例えば、
fun testAsync(): Deffered<String> {
return async {
lock.withLock {
"ABC"
}
}
}
むしろ、retrunを付けると怒られたからこのままにしたけど。return@asyncってラベルつけるればいいのか。
ラベルつけない場合はどうなってんだこれ。
inline の場合は return の意味がちょっと変わっちゃうんじゃない?
後、
https://ideone.com/RIMEHi
で、
val t = Test()
t.update()
にすると、propertyが変更されないっぽいんですけど、なんででしょうか？？
Android環境でコルーチンを使ってます
よろしくお願いします。 あれ、そういや、>>787でfieldってラムダ式の中から変更できるの？？ え、Androidやろうと思って今ならKotlinかなって思って調べてたのに。
>>787
Androidやコルーチンであることは直接の関係が無く
インラインでないラムダとprivate setの組み合わせが影響しているようだ
https://ideone.com/aLit2X
↑これの「4」が出力されるケースと同じでsetの処理を通らずに
バッキングフィールドに直に代入されてると思う
バグか仕様か断言はしないけど、多分コンパイラのバグじゃないかな >>791
うぉぉ。ありがとう。コルーチン関係なかったのか。
まだ、インラインとか勉強してなくてさっぱりだけどw
この前の>>658も俺だし、
真面目にkotlinで開発しようと思って2週間ぐらいでこのザマとか
なんなのkotlinの品質。笑えないな。 そうだよね。俺もちょっと前というか昨日もそうだけど、>>787のまた変な動きに出くわして
さすがにうんざりしてIssue Trackerのぞいたけど、前のも報告されてないっぽいよねww
つか、前のやつは単なるコンパイラのバグですまされない仕様修正とか入りそうな予感してるんだけど。
まぁ、現状の仕様ってのがなんだかよくわからんけど。 コンパイラのバグはバグとして直すのが当然だけど
この前のバッキングフィールドの初期化回避や
setter内のインラインでないラムダからバッキングフィールドにアクセスするのを
普通のアプリ開発として書いているのなら止めた方が良いと思う
個人的な感覚では動作以前に「コンパイルが通るべきでは無いコード」だと思うので
仕様がないとバグかそうでないか判断できないが仕様はどこにあるんだ？
kotlinで3000行くらいすでに書いちゃったけど、とりあえず、private setをpublic setに直して回避・・
しばらくflutterで遊んでくるか
ブックマークへ