JetBrainsが開発した期待の新言語Kotlinについて語りましょう
https://kotlinlang.org
前スレ
Kotlin
http://2chb.net/r/tech/1456505161/
https://kotlinlang.org
前スレ
Kotlin
http://2chb.net/r/tech/1456505161/
kotkot煮込んだJavaのスープ
ギャラクシーエンジェルのタイトルみたいだな
Google、KotlinをAndroidアプリ開発言語に選定
http://jp.techcrunch.com/2017/05/18/20170517google-makes-kotlin-a-first-class-language-for-writing-android-apps/
Kotlinのスキルを持たないAndroid開発者は恐竜のようになるリスクに直面。Realmが予測
http://www.publickey1.jp/blog/17/kotlinandroidrealm.html
http://jp.techcrunch.com/2017/05/18/20170517google-makes-kotlin-a-first-class-language-for-writing-android-apps/
Kotlinのスキルを持たないAndroid開発者は恐竜のようになるリスクに直面。Realmが予測
http://www.publickey1.jp/blog/17/kotlinandroidrealm.html
恐竜がいたら玉乗り仕込みたいね
名前の可愛さでいったら右に出るものがいない
全然流行ってないね・・・
独自クラスのオブジェクトを突っ込んだListのソート処理がKotlinだと楽すぎてワロタ
Comparatorとか実装する必要すらない
Comparatorとか実装する必要すらない
>>8
流行り初めてんだよ。ようやっと日本語の入門書が増え始めたんだから。
まずはAndroidアプリ用で使う人が増えると思う。
流行り初めてんだよ。ようやっと日本語の入門書が増え始めたんだから。
まずはAndroidアプリ用で使う人が増えると思う。
海外だとアプリはもうKotlinがデフォルトらしい
http://tech.gunosy.io/entry/droidconNYC-2017
http://tech.gunosy.io/entry/droidconNYC-2017
Kotlinの仕事にありつけてないお前ら全員失業ｗｗｗざまああｗｗｗｗ
kotlinインアクション買った人いる？良さそう？
ちょっとカジってみたけど、JavaとかC#とかScalaとかF#とかをごった煮にした感じだね
イマイチ新鮮味が無いけど、JVMでAndroidやらSpringやらで使えるっていうのが重要なのかな
イマイチ新鮮味が無いけど、JVMでAndroidやらSpringやらで使えるっていうのが重要なのかな
下手に新機軸で目新しかったらScalaの轍を踏んでしまうだけだからな
Javaと併用するベターJavaの範囲を逸脱しなかったことでここまでの地位を短期間で得たのだ
ほどほどって何事も大事ね
Javaと併用するベターJavaの範囲を逸脱しなかったことでここまでの地位を短期間で得たのだ
ほどほどって何事も大事ね
>>9
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
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
>>17
逆に言うと中途半端で
わざわざ覚えるのに
新しく使えるものが少ない
でもまあScalaだと
そこそこ難しくなってしまうから
Kotlinの方が流行るだろうね
逆に言うと中途半端で
わざわざ覚えるのに
新しく使えるものが少ない
でもまあScalaだと
そこそこ難しくなってしまうから
Kotlinの方が流行るだろうね
ボイラープレート自体が消えるということに喝采した人が多い
「それくらいIDEが自動で大量に書いてくれる」ではなく「そもそも無い」が好まれるのだ
視覚情報大事
「それくらいIDEが自動で大量に書いてくれる」ではなく「そもそも無い」が好まれるのだ
視覚情報大事
android専用みたいになってるけど、
javaでやれることは、
全部kotlinでもできるの？
javaでやれることは、
全部kotlinでもできるの？
誰だそんなAndroid専用とか変なこと言ってるの…
ただほんのちょっと、現時点でのJavaの新規用途や一般人用途がAndroidアプリ作成しかないだけじゃないか…
ということで「ふつうの」Javaが使えるとこはだいたいKotlinが使えるよ
企業に勤めてるような人でもない限り Javaプログラミング＝Androidアプリプログラミング なのでそんな認識になってるだけだ
組み込みとかあのへんの大変そうなとこはたぶんまだ無理だけど、そういうとこに使えるかどうか気になるような人はKotlinが動作しうるかどうかは見てわかるだろう
ただほんのちょっと、現時点でのJavaの新規用途や一般人用途がAndroidアプリ作成しかないだけじゃないか…
ということで「ふつうの」Javaが使えるとこはだいたいKotlinが使えるよ
企業に勤めてるような人でもない限り Javaプログラミング＝Androidアプリプログラミング なのでそんな認識になってるだけだ
組み込みとかあのへんの大変そうなとこはたぶんまだ無理だけど、そういうとこに使えるかどうか気になるような人はKotlinが動作しうるかどうかは見てわかるだろう
ていうか Java にできて Kotlin にできない事ってあるのか？
そんなもん無いようにしか見えないんだが。
そんなもん無いようにしか見えないんだが。
バグの量産はJavaにしか出来ない
>>24
吐き出すのはただのclassファイルなんで、滅多なことではないと思うんだけど、断言できるほど知識もないのでドリームを残しておいた
きっと凄い人が無償で調べてカッコよく回答してくれるはずだ
吐き出すのはただのclassファイルなんで、滅多なことではないと思うんだけど、断言できるほど知識もないのでドリームを残しておいた
きっと凄い人が無償で調べてカッコよく回答してくれるはずだ
これまでのまとめ
Java にできて Kotlin にできないこと
1. バグの量産
2. 奴隷の大量使い捨て
Java にできて Kotlin にできないこと
1. バグの量産
2. 奴隷の大量使い捨て
kお前らが作ったら何使ってもバグの量産だろwww
存在がバグみたいなお前に言われたくねーよｗｗｗ
恐竜になれる
読みで画像検索すると語感や方向性がよく分かる
画像検索 じゃば
https://www.google.co.jp/search?tbm=isch&q=%e3%81%98%e3%82%83%e3%81%b0
画像検索 ことりん
https://www.google.co.jp/search?tbm=isch&q=%e3%81%93%e3%81%a8%e3%82%8a%e3%82%93
画像検索 じゃば
https://www.google.co.jp/search?tbm=isch&q=%e3%81%98%e3%82%83%e3%81%b0
画像検索 ことりん
https://www.google.co.jp/search?tbm=isch&q=%e3%81%93%e3%81%a8%e3%82%8a%e3%82%93
flag |= x
flag &= ~x
これを
flag = flag or x
flag = flag and x.inv()
こう書かなきゃならない冗長さ
開発者曰く、可読性の問題なら関数にすればいいじゃんと
flag &= ~x
これを
flag = flag or x
flag = flag and x.inv()
こう書かなきゃならない冗長さ
開発者曰く、可読性の問題なら関数にすればいいじゃんと
超一般論としては論理演算子付き自己代入はそれによって陰に実行されるものがあんまり自明ではないので使わないほうがよい
あんまり自分の分析能力を信用してはイカンよ
あんまり自分の分析能力を信用してはイカンよ
Kotlin in action読んだ
良いよ
良いよ
Kotlinインアクションはいいことはいいのだが索引が貧弱で、
例えばソートしようと思って索引見ても sort が載っていない。
じゃあ List のメソッドだろうということで List を探しても載っていない。
ということでリファレンスとして使えない。内容同じままでいいから索引を大幅拡充したの出して欲しい。
例えばソートしようと思って索引見ても sort が載っていない。
じゃあ List のメソッドだろうということで List を探しても載っていない。
ということでリファレンスとして使えない。内容同じままでいいから索引を大幅拡充したの出して欲しい。
結構難しい言語だね
エルビス演算子ってエルビス・プレスリーからきてたんだな
エルビス・プレスリー知らない人も多そうだし、常識として知っててもなにがどうエルビスなのかわからん人もいそうだ
袖のじゃらじゃらした飾りだと思ってる人もいるけど違うからね ? は髪型だからね
袖のじゃらじゃらした飾りだと思ってる人もいるけど違うからね ? は髪型だからね
Kotlin in actionのおかげでやっとflatmapの意味が分かった
ifとか式にできるくせに、代入文は式にできねぇの？？しょっぺぇ。
while ((bytesRead = stream.read(bytes)) != -1)
とかできねぇの？しょっぺぇ
while ((bytesRead = stream.read(bytes)) != -1)
とかできねぇの？しょっぺぇ
あれ、ひょっとして、kotlinてまだシリアライズできねぇの？？
しょっぺぇ・・・
普通にデータの保存にJavaのバイナリフォーマットのシリアライズ使ってたんだけどな・・・
あぼぼぼぼぼ。
しょっぺぇ・・・
普通にデータの保存にJavaのバイナリフォーマットのシリアライズ使ってたんだけどな・・・
あぼぼぼぼぼ。
なんかかわいそう
生暖かい目で見守ってあげよう
whileはみんなそこで詰まるNE！
Kotlinは条件部分で副次作用が起こることをよしとしないのだ
数少ない「単体部分で見ればJavaより記述量多い」部分なので、
我慢して明示的に変数定義に切り分けるか、素直に組み込みのBufferedReaderとか使ってくれ
よっぽどオリジナルでない限りwhileでなんかしてたやつは「whileの外ごとまとめて」3行くらいで書ける
Kotlinは条件部分で副次作用が起こることをよしとしないのだ
数少ない「単体部分で見ればJavaより記述量多い」部分なので、
我慢して明示的に変数定義に切り分けるか、素直に組み込みのBufferedReaderとか使ってくれ
よっぽどオリジナルでない限りwhileでなんかしてたやつは「whileの外ごとまとめて」3行くらいで書ける
昔、ポインタ演算できないからJavaはしょぼい、というような主張してる奴が
たまに居たのを思い出した
たまに居たのを思い出した
Kotlinの仕事ができてないお前ら失業確定ｗｗｗ無職ざまあｗｗｗｗｗｗ
>>49
Java使ってれば違和感なく移行できますと言われつつ、実際はプチパラダイムシフトの受け入れが必要なのはちょっと不誠実かなとは思う
我々は「うっひょー○○言語や××言語のアレみたいだね！」とか喜ぶわけなんだが
Javaしかやらないような人から見たら「Javaとは全く違うだけの気持ち悪い何かがくっついてる」としか思えない可能性は高い
Java使ってれば違和感なく移行できますと言われつつ、実際はプチパラダイムシフトの受け入れが必要なのはちょっと不誠実かなとは思う
我々は「うっひょー○○言語や××言語のアレみたいだね！」とか喜ぶわけなんだが
Javaしかやらないような人から見たら「Javaとは全く違うだけの気持ち悪い何かがくっついてる」としか思えない可能性は高い
>>51
アピールしてるのは「相互運用性が高いから移行できます」であって、「違和感なく移行できます」では無いよ
そういうのを書いてる第三者の記事はありそうだけど
公式的にはむしろ関数型に力入れてるのを売りにしてる
アピールしてるのは「相互運用性が高いから移行できます」であって、「違和感なく移行できます」では無いよ
そういうのを書いてる第三者の記事はありそうだけど
公式的にはむしろ関数型に力入れてるのを売りにしてる
>>51
> Javaしかやらないような人から見たら「Javaとは全く違うだけの気持ち悪い何かがくっついてる」としか思えない可能性は高い
そうやって全く関数型やらモダン言語らしいとこ使わない違和感あるKotlinコードが出来そう
> Javaしかやらないような人から見たら「Javaとは全く違うだけの気持ち悪い何かがくっついてる」としか思えない可能性は高い
そうやって全く関数型やらモダン言語らしいとこ使わない違和感あるKotlinコードが出来そう
プロパティと型推論しか使わないのもあり？
それならできそう。
それならできそう。
>>38
Kotlin in action買おうか迷っているけど、公式サイトの解説と比べてもっと深いことが書いてあったりする?
ちなみにKotlinスタートブック は読了済み。
Kotlin in action買おうか迷っているけど、公式サイトの解説と比べてもっと深いことが書いてあったりする?
ちなみにKotlinスタートブック は読了済み。
>>54
javaとの対比だとプロパティとnull安全だな。最も有用
それ以外はコーディング的な進化だから追々覚えればよい
javaとの対比だとプロパティとnull安全だな。最も有用
それ以外はコーディング的な進化だから追々覚えればよい
俺のお気に入りのF#はなんだかんだでnull残ってるから、その点はkotlin羨ましい
残念ながらjava互換だからnullは無くならないのだよ
ガードしない場合、ぬるぽが起こる割合はJavaとほぼ同じ
言語の仕組み上安楽にガードしやすいってだけの話だからね
しない・できない・忘れてたという場合はぬるぽぬるぽぬるぽだ
コードはまさに意図した通りではなく書いた通りに動く
そこでは思想など無意味だ
言語の仕組み上安楽にガードしやすいってだけの話だからね
しない・できない・忘れてたという場合はぬるぽぬるぽぬるぽだ
コードはまさに意図した通りではなく書いた通りに動く
そこでは思想など無意味だ
Android Studioでのコード補完のパラメータ表示にInputStream!とか末尾に「！」が
ついてるんですが、これは何なんでしょうか？
ついてるんですが、これは何なんでしょうか？
IntelliJ の T! は「T か T? のどちらか」を示す
つまりNullableかどうかすらわかんねえという記号
つまりNullableかどうかすらわかんねえという記号
>>60
ありがとうございます。Java絡みのは当たり前ですが、ほぼそうなってますね。
理解しました。
ありがとうございます。Java絡みのは当たり前ですが、ほぼそうなってますね。
理解しました。
忘れてたって言ったって全部に？付けないとＪａｖａと同じにならないわけで
?付けなけりゃコンパイル通らないしNULL安全意識せざるを得ない
?付けなけりゃコンパイル通らないしNULL安全意識せざるを得ない
!! は、Nullable を、NotNull に強制変換する、危険な演算子だから、
requireNotNull 関数を使え
例えば、Java から、null が代入される場合、
String → IllegalStateException。ヌルポよりまし
String? → Nullable なのでOK
Platform Type
型を省略(String!) → デリファレンス時に、ヌルポ
Java からの戻り値がすべて、Nullable になるのは困るので、
その折衷案がPlatform Type
requireNotNull 関数を使え
例えば、Java から、null が代入される場合、
String → IllegalStateException。ヌルポよりまし
String? → Nullable なのでOK
Platform Type
型を省略(String!) → デリファレンス時に、ヌルポ
Java からの戻り値がすべて、Nullable になるのは困るので、
その折衷案がPlatform Type
Java からの戻り値をすべて、Nullable にするのは面倒なので、
そのまま使ったのが、Platform Type
デリファレンス時に、ヌルポとなるため危険！
そのまま使ったのが、Platform Type
デリファレンス時に、ヌルポとなるため危険！
めんどくせえな
Javaのほうのコードに@NonNullアノテーションつけとけば、KotlinからT!じゃなくてTとして扱える
現代的な気遣いのされてるJavaライブラリはKotlinからでも便利に扱える
シガラミがあって旧来のままのライブラリはそりゃ利用者側が手間かけるしかない
シガラミがあって旧来のままのライブラリはそりゃ利用者側が手間かけるしかない
ラッパークラス作るぐらいしか方法なさそうだな
ラッパークラスもありだし、OSSなライブラリだったらアノテーション付与してPR送るのも有用だな
Kotlinから使いやすくなりました！ みたいに言えるのはひょっとしたら売りになるかもしれんね
ことりちゃん、マジ使いやすいぜｸﾞﾌﾌ
ことりんの擬人化はよ
（・8・）
やはり擬人化が必要だな
萌えキャラで
萌えキャラで
何のために必要なの？
それは君には中々理解できない理由による。
例えば以前Appleが傾いた時にジョブズが復帰してiMacを作ってAppleは救われたが、iMacはハードウェアとしてそんなに素晴らしかっただろうか？
たいして素晴らしくはないのだ。ブラウン管ディスプレイに本体入れて一体化しただけだ。しかし売れた。なぜか？
デザインがよかったからだ。コンピュータとしてはどうでもいい見た目が売れ行きに多大に影響した。
技術者から見ればどうでもよさそうなものでも甘く見てはいけないということだ。
例えば以前Appleが傾いた時にジョブズが復帰してiMacを作ってAppleは救われたが、iMacはハードウェアとしてそんなに素晴らしかっただろうか？
たいして素晴らしくはないのだ。ブラウン管ディスプレイに本体入れて一体化しただけだ。しかし売れた。なぜか？
デザインがよかったからだ。コンピュータとしてはどうでもいい見た目が売れ行きに多大に影響した。
技術者から見ればどうでもよさそうなものでも甘く見てはいけないということだ。
>>77
技術的な話をスレでされても理解できなくて不愉快だから「とにかくほかの話」をさせたがっている
知らない言語のスレなんて見なきゃいいのにね
技術的な話をスレでされても理解できなくて不愉快だから「とにかくほかの話」をさせたがっている
知らない言語のスレなんて見なきゃいいのにね
goが人気になった要因もgopher君が半分くらいあるからな。ことりんはいいな
ほんとおまえらはばかだなあ
日本の電子IT系なんてオタクの巣窟なんだから萌えキャラことりんで流行言語間違いなしやで
日本の電子IT系なんてオタクの巣窟なんだから萌えキャラことりんで流行言語間違いなしやで
うわぁ、、、
ことりんとペアプログラミングしたい
「ことりん」のライバルが「ざまりん」で草
インアクションとなんとか太郎本どっち買おう
後者は本屋で見たんだけど
後者は本屋で見たんだけど
目指すとこがちゃうからな
現在どのくらい習熟してるかにもよるかと
現在どのくらい習熟してるかにもよるかと
「たのしいRuby 第5版、2016」高橋 征義
「みんなのPython 第4版、2017」柴田 淳
「Kotlinスタートブック、2016」長澤 太郎
この辺は、日本では、避けては通れない人達
「みんなのPython 第4版、2017」柴田 淳
「Kotlinスタートブック、2016」長澤 太郎
この辺は、日本では、避けては通れない人達
逆に避けなくてはいけない人達はだれ？
掌田津耶乃
掌田津耶乃
そうなの？どういう点がまずいの？
内容が薄い
なるほど。
濃いめなのは？
濃いめなのは？
掌田津耶乃は、ほとんどの言語・フレームワーク・開発環境の、本を書いてる
売れ筋では、必ず顔を出す。
売れる分野に、掌田あり！
売れ筋では、必ず顔を出す。
売れる分野に、掌田あり！
公式見て自習しろや、が通じるならセミナーとか講演会とか必要ないわけでな（いや、これに関しては別に必要ないとは思ってるが）
世の中の需要はあんまりロジカルではないのだ
世の中の需要はあんまりロジカルではないのだ
昔の河西か
入門書ばっかり書いて金儲けするのが目的なんだろう
やってみるとわかるのだが（やらなくてもいいが）、中上級者向けの本というのは全然儲からないのだ
書くの時間かかるし分厚くなって値段高くなるし売れなくなるしチェック内容増えるし時代遅れが混じるし下手すると共書だし
出来によっては「あのすごい便利な本を書いた人」という称号はいくらかの称賛になり、ひょっとしたら生活豊かルートをも開拓するかもしれないが、分は悪い
初心者向けの本をひとりで年に2冊くらい書いてたほうが、志低いと揶揄されながらもきちんと生活できるのさ
書くの時間かかるし分厚くなって値段高くなるし売れなくなるしチェック内容増えるし時代遅れが混じるし下手すると共書だし
出来によっては「あのすごい便利な本を書いた人」という称号はいくらかの称賛になり、ひょっとしたら生活豊かルートをも開拓するかもしれないが、分は悪い
初心者向けの本をひとりで年に2冊くらい書いてたほうが、志低いと揶揄されながらもきちんと生活できるのさ
粗製濫造して食う飯はうまいか
やってみるとわかるとな？
掌田津耶乃って何者? (Late 2012)
http://egg.2ch.net/test/read.cgi/mac/1349360916/
1 ：Mac Fan Letterより転載 [sage] ：2012/10/04(木) 23:28:36.22 ID:ZGQCgQTH0
● ネットサーフの溺死者たち
「友がみな我より偉く見ゆる日よ」
「2チャンネル」という最低最悪のサイトがある。
http://egg.2ch.net/test/read.cgi/mac/1349360916/
1 ：Mac Fan Letterより転載 [sage] ：2012/10/04(木) 23:28:36.22 ID:ZGQCgQTH0
● ネットサーフの溺死者たち
「友がみな我より偉く見ゆる日よ」
「2チャンネル」という最低最悪のサイトがある。
>>94
器用貧乏とは言ったものの、翻訳書が原書+1000円くらいの値段になることがざらなことを考えると
英語の公式チュートリアルを訳しただけでも、値段相応なのかもしれん。
しかし、著者のことをよく知らずにタイトルだけでうっかり買ってしまったものの身にもなって欲しい(自己責任)
深く理解した上で書かれた本かどうかは、(本を必要とするレベルの人には)立ち読み程度ではわからない。
器用貧乏とは言ったものの、翻訳書が原書+1000円くらいの値段になることがざらなことを考えると
英語の公式チュートリアルを訳しただけでも、値段相応なのかもしれん。
しかし、著者のことをよく知らずにタイトルだけでうっかり買ってしまったものの身にもなって欲しい(自己責任)
深く理解した上で書かれた本かどうかは、(本を必要とするレベルの人には)立ち読み程度ではわからない。
Kotlinに限らずあれもこれも全く初心者に寄り添っていないことを鑑みると、初心者向けの本を書くというだけで価値があるのやもしれぬ
あなたがライブラリマニュアル作るときに開発環境のダウンロードやプログラミング言語の文法から説明しないのと同じだ
あなたがライブラリマニュアル作るときに開発環境のダウンロードやプログラミング言語の文法から説明しないのと同じだ
「単純に意味や役割が似通ってるメソッドを集めただけのメソッド集」を表すものってないですかね
Rubyでいうmoduleみたいなやつ
特にどのオブジェクトに属してるってわけでもない、誰も初期化しなくてよくてすぐメソッドが使えるやつ
いまobjectでシングルトンクラスにしてるけど、なんか漂う特別感に違和感が
Rubyでいうmoduleみたいなやつ
特にどのオブジェクトに属してるってわけでもない、誰も初期化しなくてよくてすぐメソッドが使えるやつ
いまobjectでシングルトンクラスにしてるけど、なんか漂う特別感に違和感が
適当なネームスペースで、メソッドじゃなくて関数だけ複数定義したファイルを作ればいいんじゃないかな？
ああなるほど、packageで分ければいいのか…
シングルトンクラスの中に書くよりはしっくりくる…ような…気が…す…うん、そういうものだと思うことにします
シングルトンクラスの中に書くよりはしっくりくる…ような…気が…す…うん、そういうものだと思うことにします
Kotlinで以下の処理をスマートに書き直したらどうなりますか
int idx = -1;
for (int i=0; i<list.size(); i++) {
if (list[i].data == data) {
idx = i;
break;
}
}
(idxを使った処理)
int idx = -1;
for (int i=0; i<list.size(); i++) {
if (list[i].data == data) {
idx = i;
break;
}
}
(idxを使った処理)
val idx = list.indexOfFirst{ it.data == data }
逆引き、ポケットリファレンスものを出して
>>110
サンクス！まさか1行でできてしまうとは。。
Android Studioに貼り付けてもこうはならないよね
サンクス！まさか1行でできてしまうとは。。
Android Studioに貼り付けてもこうはならないよね
Kotlin、、怖ろしい子。。
じゃばの妹ことりん
ことりん星からやったきたことりん
お前ら「よーし新しく覚えたKotlinのあんな技こんな技使ってコーディングするぞー」
～ 数日後コードレビュー ～
リーダー「あー、これ全部Javaと同じ感じで作り直しといてネ、ヨロシク」
～ 数日後コードレビュー ～
リーダー「あー、これ全部Javaと同じ感じで作り直しといてネ、ヨロシク」
ゆうこりん
そして逆コンパイルしたJavaを提出して盛大に怒られる...みたいな。
こんなことで連投してスマン
こんなことで連投してスマン
そんな会社辞めちまえ
君、セミコロンを忘れているよ。
；
println("；")
ぷりんとりん
そういや print って印刷って意味だよな。もはや時代も変わり誰も印刷してないのにプログラミング言語では print で出力が定番になっちゃったな。
厳密には印字なのでギリギリ合ってる
原初のBASICのPRINT対象はテレタイプだったから印刷するという意図とはそもそもちょっとだけ違う
原初のBASICのPRINT対象はテレタイプだったから印刷するという意図とはそもそもちょっとだけ違う
ポワトリン
ブラウン管に文字を焼き付けるから print
無理があるな。
無理があるな。
printの古い意味は押すだからな
そういえば昔、プリントごっこで押しまくってたな
putもあるやん
押して痕跡残すようなのが print だな。
kotlinの文法ってちょっと省略しすぎだし、やりすぎじゃねぇの・・・
C#の方がバランス取れてるわ。
C#の方がバランス取れてるわ。
慣れの問題だと思うけどなあ
抽象化と少ないコードが正義な昨今の風潮ではこういう文法が受ける
本当にこれで良かったのかは後10年ぐらいしたらわかるだろう
本当にこれで良かったのかは後10年ぐらいしたらわかるだろう
CP/M80上で動くKotlin処理系が無い…
これはこれで同じこと書いてる感がん～って感じではある
class MyData(name: String, age: Int){
val name = name
val age = age
}
引数にval書けちゃうことでの「見かけ一貫性の破れ」と「引数もチェックしなければならなくなったという手間」は肯定する
class MyData(name: String, age: Int){
val name = name
val age = age
}
引数にval書けちゃうことでの「見かけ一貫性の破れ」と「引数もチェックしなければならなくなったという手間」は肯定する
というかあれはdataクラスを便利に書くためだけのギミックな気がするぞ
しかし言われてみれば視線的にめっちゃ遠いのはその通りだな、家のやつは今度使わずに書いてみるか
しかし言われてみれば視線的にめっちゃ遠いのはその通りだな、家のやつは今度使わずに書いてみるか
KotlinがNull安全といっても結局、Javaなどの使用するクラスライブラリがNull安全じゃないからな。
Kotlinだけで閉じてればいいけど、Kotlin最小限のライブラリしか用意してねぇし。どうすりゃいいんでしょうか？？
「！！」演算子積極的に使えばいいの？
Kotlinだけで閉じてればいいけど、Kotlin最小限のライブラリしか用意してねぇし。どうすりゃいいんでしょうか？？
「！！」演算子積極的に使えばいいの？
自分のメソッドは全部ヌルポ無しにすればいい。
うん。自分のメソッドはNot Nullにしてるけど、その実装で結局、Javaのクラスが絡む事多いから、
その実装部分で「！！」連発してるんだけど、なんだかなぁ・・・・・
その実装部分で「！！」連発してるんだけど、なんだかなぁ・・・・・
ぬるぽが出そうならトラップするという記法がKotlinにはいくつもあるだろそれ使え
chackNotNull(nullable){ "ぬるぽだけは阻止しましたが例外で落ちますさようなら" }
nullable?.aaa?.bbb ?: throw RuntimeException("エラーとぬるぽって死ぬ点で大差なくね？")
when(){
nullable == null -> println("おかあさんに言いつける")
isSomeState -> nullable.xxx.yyy // 文脈上nullが来得ないので ?. で書かなくていい
}
chackNotNull(nullable){ "ぬるぽだけは阻止しましたが例外で落ちますさようなら" }
nullable?.aaa?.bbb ?: throw RuntimeException("エラーとぬるぽって死ぬ点で大差なくね？")
when(){
nullable == null -> println("おかあさんに言いつける")
isSomeState -> nullable.xxx.yyy // 文脈上nullが来得ないので ?. で書かなくていい
}
ああまた空whenに()つけてる
毎回間違って毎回IDEに文句言われるんだよなこれ
毎回間違って毎回IDEに文句言われるんだよなこれ
>ぬるぽが出そうならトラップ
ぬるぽが出そうというより、Javaのクラスから返される型は「型名!」ってAndroid Studioを
表示されてて、この型ってNullableの「型名?」と同じでNullチェックしないといけないと思ってて
「!!」連発してたんだが、これ違うな・・・
「型名!」ってNullチェックしなくてもいいのか・・・
つか、言語仕様上どんな扱いになってんだこれ・・
ぬるぽが出そうというより、Javaのクラスから返される型は「型名!」ってAndroid Studioを
表示されてて、この型ってNullableの「型名?」と同じでNullチェックしないといけないと思ってて
「!!」連発してたんだが、これ違うな・・・
「型名!」ってNullチェックしなくてもいいのか・・・
つか、言語仕様上どんな扱いになってんだこれ・・
T? と T or T? は違うよ
Nullableかどうかすらわからない後者の場合はnullチェックしなくてもコンパイルは通るよ
「だってそれはNullableではないから」
まあ、そしてぬるぽが出るんだけども
Kotlin的にはnullチェックは不要だけどIDE的にはnullが入りうることがわかってるので気を付けてね！ の ! だ
Nullableかどうかすらわからない後者の場合はnullチェックしなくてもコンパイルは通るよ
「だってそれはNullableではないから」
まあ、そしてぬるぽが出るんだけども
Kotlin的にはnullチェックは不要だけどIDE的にはnullが入りうることがわかってるので気を付けてね！ の ! だ
>>155
ありがとうございます。
Platform Typesについてしっかり読んでませんでした。そこに色々書いてありましたね。
ありがとうございます。
Platform Typesについてしっかり読んでませんでした。そこに色々書いてありましたね。
>T? と T or T? は違うよ
T or T?がプラットフォーム型というやつですかね。で、プラットフォーム型ではNullチェックが緩和される
って書いてありましたね。
T? と T or T? は同じと勘違いしてました。要はT or T?か分からないから、よりたくさん表現できるT?として扱えばいいし、
そうなってるのかと勘違いしてました。
T or T?がプラットフォーム型というやつですかね。で、プラットフォーム型ではNullチェックが緩和される
って書いてありましたね。
T? と T or T? は同じと勘違いしてました。要はT or T?か分からないから、よりたくさん表現できるT?として扱えばいいし、
そうなってるのかと勘違いしてました。
つか、デバッグしてて思ったけど、C#のusing (resource)やlock文に相当する言語組み込みの
文がkotlinにないのがちょっとめんどくさいよね。ステップオバーで順にどんどん進めねぇじゃねぇか・・
inputStream.use {
// いちいちここにブレークポイント設定しないと・・・
}とかだと、実態は関数呼び出しだから、ステップオーバーだと、内部のブロック飛び越えちゃう・・
文がkotlinにないのがちょっとめんどくさいよね。ステップオバーで順にどんどん進めねぇじゃねぇか・・
inputStream.use {
// いちいちここにブレークポイント設定しないと・・・
}とかだと、実態は関数呼び出しだから、ステップオーバーだと、内部のブロック飛び越えちゃう・・
ステップイン/ステップアウトではだめなのか
ああ、ステップインで行けたね。ステップインすると、最初useなどの拡張関数の方にぶっとぶかと思ったけど、
自分のブロックの方に直接飛べるのか。
まぁ、オーバー・インを切り替えるのひと手間だけど、まぁそれぐらいなら。
自分のブロックの方に直接飛べるのか。
まぁ、オーバー・インを切り替えるのひと手間だけど、まぁそれぐらいなら。
正直、AndroidのJavaの代替としてKotlinを使うなら、Android Studio 3.0でJavaで全APIレベルでラムダ式が
使えるようになったらしいし、後、Javaにvarなどのローカル変数の型推論あたりがくれば、Javaでも
いいかなと思うが(async/awaitもほしいけど)、Kotlin for JavaScriptの存在を知って、
ちょうど、JavaScriptとかスクリプト言語を本格的に使った事なく動的型付け言語使いたくない自分にぴったしだと
思ってKotlin覚えてみようかなと思ってきた。
Kotlin,JavaScriptでググってもあんま引っかからんけど、TypeScriptとかにとって代わったりしそうじゃねぇか？？
使えるようになったらしいし、後、Javaにvarなどのローカル変数の型推論あたりがくれば、Javaでも
いいかなと思うが(async/awaitもほしいけど)、Kotlin for JavaScriptの存在を知って、
ちょうど、JavaScriptとかスクリプト言語を本格的に使った事なく動的型付け言語使いたくない自分にぴったしだと
思ってKotlin覚えてみようかなと思ってきた。
Kotlin,JavaScriptでググってもあんま引っかからんけど、TypeScriptとかにとって代わったりしそうじゃねぇか？？
>>161
> Javaにvarなどのローカル変数の型推論あたりがくれば
それ実現されるまでまってられっかよ
> Javaにvarなどのローカル変数の型推論あたりがくれば
それ実現されるまでまってられっかよ
Haxe(ヘックス)はOSSで、JSに型チェックを付けたような言語で(altJS)、
JS(ES5), Flash, PHP, C++, Java, C#, Python, Lua に書き出せる。
Windows8.1対応。IDEは、FlashDevelop
このサイトで、ブラウザでプログラミングして、実行できる
Try Haxe !
try.haxe.org/
Kotlin = Java + Groovy
Haxe, Kotlin, Ruby をやると、他の言語がクソに見える
JS(ES5), Flash, PHP, C++, Java, C#, Python, Lua に書き出せる。
Windows8.1対応。IDEは、FlashDevelop
このサイトで、ブラウザでプログラミングして、実行できる
Try Haxe !
try.haxe.org/
Kotlin = Java + Groovy
Haxe, Kotlin, Ruby をやると、他の言語がクソに見える
Hexe ってドイツ語で魔女って意味だな
kotlinから始めたら挫折して、
結局Javaの勉強再開しました。
何個かアプリ作れるようになったけどまだまだ。
Java覚えたらkotlinまで追いつきたい。
結局Javaの勉強再開しました。
何個かアプリ作れるようになったけどまだまだ。
Java覚えたらkotlinまで追いつきたい。
Javaで動くアプリ作れてKotlin書けないってのもわりとレアケースだと思うのだが（完全に全くJava以外の経験がないとか？）
まあ個人の進度に文句もないしKotlinはしばらく逃げないので焦らずお好きにやっていただきたい
まあ個人の進度に文句もないしKotlinはしばらく逃げないので焦らずお好きにやっていただきたい
>>167
Javaの勉強途中でちょうどkotlinが盛り上がってて、
両方覚えられる！と欲張った結果、
なんか情報も少なく、混乱して挫折。
とりあえずJavaで慣れたらkotlinもやってみます。
Javaの勉強途中でちょうどkotlinが盛り上がってて、
両方覚えられる！と欲張った結果、
なんか情報も少なく、混乱して挫折。
とりあえずJavaで慣れたらkotlinもやってみます。
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016
ngsw tr
プログラミング言語初学に向かないのは多分間違いない
C#のusingもJavaのtry-with-resourcesもkotlin.io.useも気に入らない
GCだからC++やSwiftのようなデストラクタまでは無くてもいいけど
せめて use val xx = ... のようにキーワード付き変数の場合に
スコープアウトでcloseする構文を用意して欲しい
後処理の指定ごときでいちいちブロックスコープ増やすなと
GCだからC++やSwiftのようなデストラクタまでは無くてもいいけど
せめて use val xx = ... のようにキーワード付き変数の場合に
スコープアウトでcloseする構文を用意して欲しい
後処理の指定ごときでいちいちブロックスコープ増やすなと
そーゆークラスを作ればいい
内部的にはそうしてても使う側が意識しなきゃそれでいい
内部的にはそうしてても使う側が意識しなきゃそれでいい
StackOverFlowで「○○するにはどうすればいいですか」に対して
自作の20行くらいの関数返して「こうすれば1行で書ける」とか言う回答者みたいだなｗ
自作の20行くらいの関数返して「こうすれば1行で書ける」とか言う回答者みたいだなｗ
例えばこれを
openCamera(id).use { dev ->
dev.video().use { vidIn ->
File(dstPath).outputStream().use { output ->
val vidOut = videoWriter(output)
vidIn.eachFrame { frame ->
filter.write(frame, vidOut)
return checkContinue()
}
}
}
}
このように
use val dev = cameraOpen(id)
use val vidIn = dev.video()
use val output = File(dstPath).outputStream()
val vidOut = videoWriter(output)
vidIn.eachFrame { frame ->
filter.write(frame, vidOut)
return checkContinue()
}
openCamera(id).use { dev ->
dev.video().use { vidIn ->
File(dstPath).outputStream().use { output ->
val vidOut = videoWriter(output)
vidIn.eachFrame { frame ->
filter.write(frame, vidOut)
return checkContinue()
}
}
}
}
このように
use val dev = cameraOpen(id)
use val vidIn = dev.video()
use val output = File(dstPath).outputStream()
val vidOut = videoWriter(output)
vidIn.eachFrame { frame ->
filter.write(frame, vidOut)
return checkContinue()
}
次点で、golangのdeferのように
val dev = cameraOpen(id)
defer{dev.close()}
val vidIn = dev.video()
defer{vidIn.close()}
val output = File(dstPath).outputStream()
defer{output.close()}
val vidOut = videoWriter(output)
vidIn.eachFrame { frame ->
filter.write(frame, vidOut)
return checkContinue()
}
としたい
usingやuse関数での書き方が駄目とまでは言わないが俺は気に入らない
val dev = cameraOpen(id)
defer{dev.close()}
val vidIn = dev.video()
defer{vidIn.close()}
val output = File(dstPath).outputStream()
defer{output.close()}
val vidOut = videoWriter(output)
vidIn.eachFrame { frame ->
filter.write(frame, vidOut)
return checkContinue()
}
としたい
usingやuse関数での書き方が駄目とまでは言わないが俺は気に入らない
そういやjetbrainのIDEってjavaで出来てるんだよな。
kotlinで書き直されたりしてんのかな。そのへんどうなの？中の人とか？
kotlinで書き直されたりしてんのかな。そのへんどうなの？中の人とか？
try-with-resourcesみたいに「ここでリソース開いてるしエラーも起こりうるぞ！」って明示してくれるのが好き
文句の本質的には「ブロックネスト深すぎて見かけの空白多くてキモい」ってだけだよねコレ
まあ見かけはかなり重要なのだが
どこでcloseが起こるかわかるほうがいいとは思うけどな
ブロック深いのとは別件な気がする
まあ見かけはかなり重要なのだが
どこでcloseが起こるかわかるほうがいいとは思うけどな
ブロック深いのとは別件な気がする
kotlinはまず開発環境をもっと整えてほしいわ。
特にVisual Studio Codeで無料の拡張プラグインを。
JetBrainはIDEを打ってる会社なのかもしれんが・・
特にVisual Studio Codeで無料の拡張プラグインを。
JetBrainはIDEを打ってる会社なのかもしれんが・・
forを読めるが書けない
これだけが毎回全く覚えられない（あの形式はレガシーであって何の意味もないと思う）
イテレータでいいと思うのだが、Rangeはなにやら遅いとか言われてて憂鬱だ
これだけが毎回全く覚えられない（あの形式はレガシーであって何の意味もないと思う）
イテレータでいいと思うのだが、Rangeはなにやら遅いとか言われてて憂鬱だ
>>191
俺も分からないので是非書いて欲しい。
こちらはKotlin学習中なので重症ではない。単にわからないだけだ。
俺も分からないので是非書いて欲しい。
こちらはKotlin学習中なので重症ではない。単にわからないだけだ。
>>177
File.open(ファイル名) do |file|
処理
end
Ruby では、File.open()に、クロージャの実装である、ブロックを渡すと、
close()する必要がなくなる。
自動的に内部的に、例外処理で囲んで、finally で、close してくれる
たいていの言語で、そう
File.open(ファイル名) do |file|
処理
end
Ruby では、File.open()に、クロージャの実装である、ブロックを渡すと、
close()する必要がなくなる。
自動的に内部的に、例外処理で囲んで、finally で、close してくれる
たいていの言語で、そう
JVM版とNative版など環境がいくつかあるけど、標準ライブラリは基本共通なの？
こういう風に違うシグネチャの関数の参照はどうしたら良いのか？
https://ideone.com/jXVu5V
https://ideone.com/jXVu5V
未対応なので回避策とるくらいしか
val fa = {n:Int -> f(n) }
val fb = {n:Int, s:String -> f(n, s) }
val fa = {n:Int -> f(n) }
val fb = {n:Int, s:String -> f(n, s) }
あ。未対応だったのか。どうりでいくら調べても見つからないと思った。
それならそんな風に書くしかないね。
それならそんな風に書くしかないね。
>>199
ごめん変数/引数の型指定があれば解決出来るみたい
https://ideone.com/CzyR3A
ごめん変数/引数の型指定があれば解決出来るみたい
https://ideone.com/CzyR3A
>>200
おー。なるほど。ありがとう。
まあでも自分でシグネチャ指定して振り分ける感じに書く必要はあるということだね(Cでの関数へのポインタみたいなもんだからそうならざるを得ないか)。
おー。なるほど。ありがとう。
まあでも自分でシグネチャ指定して振り分ける感じに書く必要はあるということだね(Cでの関数へのポインタみたいなもんだからそうならざるを得ないか)。
>>196
コアの標準ライブラリは原則共通だが、JS, JVM(, Natevie)ごとに専用の「標準」ライブラリがある。
https://kotlinlang.org/api/latest/jvm/stdlib/index.html
コアの標準ライブラリは原則共通だが、JS, JVM(, Natevie)ごとに専用の「標準」ライブラリがある。
https://kotlinlang.org/api/latest/jvm/stdlib/index.html
あるメソッドの中の処理を切り出して作った1行系プライベートメソッドってあるよね
親メソッドの前に書いたほうがいい？ 後に書いたほうがいい？
親メソッドに長いJavaDoc、または長めのコメントがある場合、前に書いちゃうとプライベートメソッドが離れちゃって見難い/醜いよね
// subするメソッド
private fun subMethod() = ...
/*
* メインなことをするメソッド
* がんばってつくりました
* 3行も説明書いたのでボーナスください
*/
fun mainMethod(arg: SomeObj){
...
}
そういう意味ではメインのあとに書いたほうがいいんだけど、親メソッド読んでる最中に見たことないメソッドが出てきちゃって「ん？？」ってなるよね
fun mainMethod{
...
....subMethod(...) ← えっコレ何？
}
private fun subMethod() = ←定義ここかよおせーよ
Java書いたことないからこのへんの作法わかんないんだけど、なにか傾向とかあるのかな
親メソッドの前に書いたほうがいい？ 後に書いたほうがいい？
親メソッドに長いJavaDoc、または長めのコメントがある場合、前に書いちゃうとプライベートメソッドが離れちゃって見難い/醜いよね
// subするメソッド
private fun subMethod() = ...
/*
* メインなことをするメソッド
* がんばってつくりました
* 3行も説明書いたのでボーナスください
*/
fun mainMethod(arg: SomeObj){
...
}
そういう意味ではメインのあとに書いたほうがいいんだけど、親メソッド読んでる最中に見たことないメソッドが出てきちゃって「ん？？」ってなるよね
fun mainMethod{
...
....subMethod(...) ← えっコレ何？
}
private fun subMethod() = ←定義ここかよおせーよ
Java書いたことないからこのへんの作法わかんないんだけど、なにか傾向とかあるのかな
ＩＤＥの機能で定義に飛ぶから別に気にならない
ソースファイルを上から順に眺めていくってあんまりないなあ
ソースファイルを上から順に眺めていくってあんまりないなあ
どっちでもいいけど自分は後ろ。
定義なんてIDEでジャンプできるんだしどうでもいいでしょ。
定義なんてIDEでジャンプできるんだしどうでもいいでしょ。
>定義に飛ぶから
>定義なんてIDEでジャンプできる
なんだよ
（いろいろ眺めつつ）IntelliJ IDEAではF4かな。とう。おお。…さっきのとこ戻るにはどうすればいいんだろう
https://youtrack.jetbrains.com/issue/IDEA-119474
無理か。まあいいや
いや、それにしても固めて書いておく時の一般的なやり方とか見てて迷わない書き方とかあるのかなーと思って
>定義なんてIDEでジャンプできる
なんだよ
（いろいろ眺めつつ）IntelliJ IDEAではF4かな。とう。おお。…さっきのとこ戻るにはどうすればいいんだろう
https://youtrack.jetbrains.com/issue/IDEA-119474
無理か。まあいいや
いや、それにしても固めて書いておく時の一般的なやり方とか見てて迷わない書き方とかあるのかなーと思って
>>206
subMethodのKDocをしっかり書いておけば、ジャンプしなくてもマウスオーバーで
何をするメソッドかわかるから後置でいいのではと思う。
subMethodのKDocをしっかり書いておけば、ジャンプしなくてもマウスオーバーで
何をするメソッドかわかるから後置でいいのではと思う。
戻るのはデフォルトだとたぶん Ctrl+Alt+左
定義に飛んでその後戻るのをキーボードで素早くできるようにしとかないと作業が捗らんから、
おれはどんな環境でもAlt+ピリオドとAlt+カンマにカスタマイズする
たまにカスタマイズできない環境もあるが
定義に飛んでその後戻るのをキーボードで素早くできるようにしとかないと作業が捗らんから、
おれはどんな環境でもAlt+ピリオドとAlt+カンマにカスタマイズする
たまにカスタマイズできない環境もあるが
F4 は "Jump to Source" で、Ctrl+Button1 は "Decraration" だね
両方とも定義へ飛ぶけど、定義を選択して操作したときに "Decraration" のほうは使用箇所へ飛ぶメニューがでるね
おれは間違えて押したときにメニューでるのが面倒なのでキーにカスタマイズして使ってるのは "Jump to Source" の方
使用箇所へ飛びたいときには Find usages を使うし
両方とも定義へ飛ぶけど、定義を選択して操作したときに "Decraration" のほうは使用箇所へ飛ぶメニューがでるね
おれは間違えて押したときにメニューでるのが面倒なのでキーにカスタマイズして使ってるのは "Jump to Source" の方
使用箇所へ飛びたいときには Find usages を使うし
あー
F4でjump to sourceし
CMD+F4 (Macの場合)でタブクローズすればいいんじゃない
あと、quick definitionってのもある
F4でjump to sourceし
CMD+F4 (Macの場合)でタブクローズすればいいんじゃない
あと、quick definitionってのもある
vimのプラグイン入れてるけどcommand+[ですぐ戻れる
基本はそれですね、開いたタブを同時に閉じたい場合はcloseかな
Jump to SourceとDecrarationの違いを、もうひとつ見つけてしまった
DecrarationはAndroid環境だとリソースIDからレイアウトXMLへ飛んだりもできるのね
Jump to SourceだとリソースIDそのものの値を定義してるファイルに飛んじゃうので意味無い
やっぱデフォルトはDecrarationにしよう・・・
DecrarationはAndroid環境だとリソースIDからレイアウトXMLへ飛んだりもできるのね
Jump to SourceだとリソースIDそのものの値を定義してるファイルに飛んじゃうので意味無い
やっぱデフォルトはDecrarationにしよう・・・
haskellとか知ってると、まず宣言的コードがあって実装はあとからついてくるコードスタイルでも違和感はない。
トップダウンで見るかボトムアップで見るかの違い。
トップダウンで見るかボトムアップで見るかの違い。
まあ、IDEさまさまなところはあるにはある
IDEがなかったら全然違っていただろうなと思う事象は多い
IDEがなかったら全然違っていただろうなと思う事象は多い
IDEってEclipse？AndroidStudioのベータ？
JetBrains製以外のIDE使ってる人居るのかな
Vimは居そう
Vimは居そう
Eclipseとか原始時代の道具をまだ使ってるやつがいるのか
他の言語で使えるからな
Linuxなんてずっと原始時代のままだよ。
ん？でも Linux でも IntelliJ 使えるよ。
まだみんなviだよ。
ああ。まあ。確かにviってかvim使う方が多いが、さほど困らんなあ。
リモートデスクトップ経由でLinuxのIntelliJ＆Android Studio使ってうっひょーって言ってるよ
Emacsのkotlin-modeがぜんぜんイマイチなのはIntelliJ IDEAのせいではないかと思っている
Emacsのkotlin-modeがぜんぜんイマイチなのはIntelliJ IDEAのせいではないかと思っている
IdeaVimプラグインおすすめ
1.2がリリースですよ？
>>226
IDEAがあるせいで他がしょぼいというより、Kotlinの歴史の浅さやまだゴミのようなシェアの割にはIDEAの出来が良いんだろ
Kotlin自体がJetBrainsによってIDEAで使うために作った言語なんだから当然
IDEAがあるせいで他がしょぼいというより、Kotlinの歴史の浅さやまだゴミのようなシェアの割にはIDEAの出来が良いんだろ
Kotlin自体がJetBrainsによってIDEAで使うために作った言語なんだから当然
Kotlinはidea以外の環境を最低一つサポートしろよな。自社でIDEを売ってるからやだとかはやめてくれ。
VisualStudio Codeかatomのどっちかの軽量環境は最低どちらかサポートしろよ。
VisualStudio Codeかatomのどっちかの軽量環境は最低どちらかサポートしろよ。
言語提供側がすべきなのは処理系の提供であって
IDE云々で文句を言うのは筋違い
IDE云々で文句を言うのは筋違い
それは処理系に言う筋合いのものではないが。
最近のエコシステムに慣れすぎるとそう言いたくなるのはわからんでもないが。
最近のエコシステムに慣れすぎるとそう言いたくなるのはわからんでもないが。
いや分からん
使う側からしてみれば、言語提供側だろうが処理系だろうがどうでもいい。
ユーザーにとって使いやすくしたいとおもってて、他がやらないなら
最終的に言語提供側が提供すればいいだけだし。
ユーザーにとって使いやすくしたいとおもってて、他がやらないなら
最終的に言語提供側が提供すればいいだけだし。
もちろん、JetBrainsの開発リソースも限られてるが、そんなの使う側からしたら
それもどうでもいい。使いやすければユーザーが増える可能性あるし、使いにくければないだろう。
ただそれだけ。
それもどうでもいい。使いやすければユーザーが増える可能性あるし、使いにくければないだろう。
ただそれだけ。
>使う側からしてみれば、言語提供側だろうが処理系だろうがどうでもいい
は
>使う側からしてみれば、言語提供側だろうが言語提供側以外だろうがどうでもいい
あたりでw
は
>使う側からしてみれば、言語提供側だろうが言語提供側以外だろうがどうでもいい
あたりでw
時代はジェットブレインなんだよ
MicrosoftのVisualStudioとかいう原始時代の道具は時代遅れ
MicrosoftのVisualStudioとかいう原始時代の道具は時代遅れ
microsoftはjavaとあんまりかんけーし
かんけーし
Kotlinで文字列を返すenumを使うときは、
やっぱりJavaと同じようにnameとかtoStringを呼ばないといけませんか？
例えば↓のようなenumがあったときに
enum class Name(name: String) {
Foo("foo")
}
"foo"を使うときはこうすると思います
val name = Name.Foo.name()
しかし、name()が気に入りません。↓のようにはできませんでしょうか
val name = Name.Foo
やっぱりJavaと同じようにnameとかtoStringを呼ばないといけませんか？
例えば↓のようなenumがあったときに
enum class Name(name: String) {
Foo("foo")
}
"foo"を使うときはこうすると思います
val name = Name.Foo.name()
しかし、name()が気に入りません。↓のようにはできませんでしょうか
val name = Name.Foo
天才
>>241
MS製JVMは性能が良すぎてみなそれを使うようになり、Sunに訴えられたから捨てたんだぞ。
MS製JVMは性能が良すぎてみなそれを使うようになり、Sunに訴えられたから捨てたんだぞ。
J#だったからじゃないのか
>>243
Name.Fooがenumのメンバーを返さないのなら、enumじゃなくてもいいのではない？
Name.Fooがenumのメンバーを返さないのなら、enumじゃなくてもいいのではない？
今やUnix向けの開発者も揃ってVSCodeだもんなあ
開発環境ではMSには敵わないよ
Kotlinは遠からずVSCodeに持ってかれるだろうけど、そうなったらJetBrainsはどうするんだろうね
開発環境ではMSには敵わないよ
Kotlinは遠からずVSCodeに持ってかれるだろうけど、そうなったらJetBrainsはどうするんだろうね
アホすぎ
ジェットブレインの開発環境を使ってないのは
IT後進国の日本だけだぞ
ジェットブレインの開発環境を使ってないのは
IT後進国の日本だけだぞ
>>249
そうかもしれません
Kotlinで文字列の定数をまとめて扱うにはどうするのがベストですか？
そうかもしれません
Kotlinで文字列の定数をまとめて扱うにはどうするのがベストですか？
>>250
> 今やUnix向けの開発者も揃ってVSCodeだもんなあ
を3回くらい読んで何を指してるのかなんとなくわかった
サーバサイドのスクリプト言語プログラミングもVSCodeで行われることは増えた
EmacsでFTPやらSSHやらして一生懸命書いてた頃とは隔世の感はある
（いや、まあ、ぶっちゃけるなら、Emacs+xx-modeがVSCode+プラグインに置き換わっただけではあるが）
VSCodeはElectronを捨てることができた瞬間に勝利が確定する
> 今やUnix向けの開発者も揃ってVSCodeだもんなあ
を3回くらい読んで何を指してるのかなんとなくわかった
サーバサイドのスクリプト言語プログラミングもVSCodeで行われることは増えた
EmacsでFTPやらSSHやらして一生懸命書いてた頃とは隔世の感はある
（いや、まあ、ぶっちゃけるなら、Emacs+xx-modeがVSCode+プラグインに置き換わっただけではあるが）
VSCodeはElectronを捨てることができた瞬間に勝利が確定する
>>252
Javaからの見え方を気にしないのならこれでもいいかな？
object Name { val Foo = "foo" }
Javaからの見え方を気にしないのならこれでもいいかな？
object Name { val Foo = "foo" }
IntelliJをバージョンアップしたらSpekテスト設定のSpec欄ヨコのSearch by Nameが動かなくなった
これまではモジュール適当に指定したら勝手に探して候補出してくれてマウスぽちぽちで済んだのだが、なんかspec欄を自力入力で埋めないといかん
それともこれは普通は使わない所だったのだろうか
これまではモジュール適当に指定したら勝手に探して候補出してくれてマウスぽちぽちで済んだのだが、なんかspec欄を自力入力で埋めないといかん
それともこれは普通は使わない所だったのだろうか
多分日本で俺だけだろうけど、
Kotlinの公式PDFはフォントのAlignがずれてて
読み始めて1分しない内に直視に耐えられなくなってしまう…。
直そうと頑張ってみたが有料ソフト使うしかないみたいで諦めた。
しかし治ってたら嬉しいなと定期的にダウンロードし直してしまう。
Kotlinの公式PDFはフォントのAlignがずれてて
読み始めて1分しない内に直視に耐えられなくなってしまう…。
直そうと頑張ってみたが有料ソフト使うしかないみたいで諦めた。
しかし治ってたら嬉しいなと定期的にダウンロードし直してしまう。
"sourcefiles"という名の.ktソースファイル名一覧ファイルを作り、
kotlinc @sourcefiles
を走らせると、
error: source file or directory not found: @sourcefiles
が画面に表示されてしまいます。
javac @sourcefiles
scalac @sourcefiles
に相当する機能はkotlincには無いのでしょうか？
kotlinc @sourcefiles
を走らせると、
error: source file or directory not found: @sourcefiles
が画面に表示されてしまいます。
javac @sourcefiles
scalac @sourcefiles
に相当する機能はkotlincには無いのでしょうか？
質問の答えは知らないので他の人に任せるけど
ビルドはkotlinc直よりGradle使うことを勧める
ビルドはkotlinc直よりGradle使うことを勧める
またそんなこと言って。
あなたはいつも他人任せね。
いいかげん私も待ちくたびれちゃうわ。
あなたはいつも他人任せね。
いいかげん私も待ちくたびれちゃうわ。
なんで女言葉なの？
だって女と思わせた方が答えが出やすいんですもの
Gradle, Vagrant は、yaml, XML, JSON のような、単なる設定ファイルではなく、
それ自体が、Groovy, Ruby の、クロージャ・ブロックで囲まれた、
スコープを持つソースコードであるから、変数宣言や処理も書ける
それ自体が、Groovy, Ruby の、クロージャ・ブロックで囲まれた、
スコープを持つソースコードであるから、変数宣言や処理も書ける
うふ
(´・ω・｀)うふふ
リアルの女と接点がなく、妄想で女はこうだろうと決めて話してるのがわかる
昭和生まれのジジイですわ
昭和生まれのジジイですわ
謎のマジレスマンが居ますね
マジレズマン
マジレスマンつまらないわね
(´・ω・｀)ほんとよね
Kotlin Advent Calendar がAndroid以外の話題多めだな
ここでナチュラルにIntellijIDEA の話題だしちゃったけど
Android以外の人も IntellijIDEA を買って使ってるのかねえ？
ここでナチュラルにIntellijIDEA の話題だしちゃったけど
Android以外の人も IntellijIDEA を買って使ってるのかねえ？
12/18にこの本が出るようだ。Amazonには本の表紙画像がまだ出ていない。
Androidアプリ開発のためのKotlin実践プログラミング
http://amzn.asia/4GO28m2
Androidアプリ開発のためのKotlin実践プログラミング
http://amzn.asia/4GO28m2
KotlinはAndroidが対応したってだけでそのためだけに使う人は少数派やろ
いやあ、しかし楽にはなりそうだからねえ、流行ると思うけどねえ。
なんだ秀和システムか
なぁーんだ
cmで始まってdpで終わってるからどこかのレビューページから飛んだURLだと思うんだが
なにもしないとcm_cr_dpなんだけどな
cpが入ってるってことは「この商品を見た後に買っている」を1回表示してるのかもしれない
なにもしないとcm_cr_dpなんだけどな
cpが入ってるってことは「この商品を見た後に買っている」を1回表示してるのかもしれない
cm_sw_ ... _dp はシェア用URLの生成形式だね
ツイッター用ならcl_twで超わかりやすいんだがr_cp_epはなんだろう
ツイッター用ならcl_twで超わかりやすいんだがr_cp_epはなんだろう
lateinit var value: Int
って書いたら'lateinit' modifier is not allowed on properties of primitive typesのエラーになるんですが、
どう書き直したらいいんでしょうか
var value: Int? = null
って書いて、
if (value == null) {
value = initValue()
}
ってするしかないんでしょうか。
って書いたら'lateinit' modifier is not allowed on properties of primitive typesのエラーになるんですが、
どう書き直したらいいんでしょうか
var value: Int? = null
って書いて、
if (value == null) {
value = initValue()
}
ってするしかないんでしょうか。
プリミティブ型にlateinitは必要ないからつけられない
>>288
試してないけど
var var value by { var value: Int }
ではだめ?
試してないけど
var var value by { var value: Int }
ではだめ?
で、一番いい入門書は？
>>291
自分はスタートブックを推す。
Javaを知っていることを前提としない入門書の存在を自分は知らない。
自分はスタートブックを推す。
Javaを知っていることを前提としない入門書の存在を自分は知らない。
>>292
慌てて修正したらlazy落としていたorz orz
var value by lazy { initValue() }
連投申し訳ない。これで違っていたら目も当てられんが、それもすみません。と誤っておきます。
慌てて修正したらlazy落としていたorz orz
var value by lazy { initValue() }
連投申し訳ない。これで違っていたら目も当てられんが、それもすみません。と誤っておきます。
>>291
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016
一番良いもクソも無い。
この1冊しか出ていないだろ
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016
一番良いもクソも無い。
この1冊しか出ていないだろ
ありがとうこの世界の片隅にうちを見つけてくれて
アスペは質疑応答解説に使えねーなーもう
>>288
なぜlateinitを使うかというと「初期値というものがうまく定義できなくてうまく初期化できないから」だ
※実際にはjavaでprimitive typeであるものはnull代入できないからという理屈なのだが知らなくていい
Intとかは0とか-1とかで初期化できるだろ、最初にvarで0や-1入れとけ
Nullableもnullで初期化できるからlateinit使わずにただのvarでnull入れとけ
で、どーしても遅延初期化を使いたいなら
var value: Int by Delegates.notNull<Int>()
とか書くと形式上遅延初期化になる。むろん二度手間だが、遅延初期化という目的は一応達成される
こんなごっついことせずに素直に0とか入れておいたほうがいいんじゃねーかなと思った感覚は正しい。0入れとけ0
あとはちらっと出てたけどby lazyで
val value: Int by lazy { initValue() }
と書くことでも一応達成される。こっちだとvalで書けるので好まれることが多いみたいだね
>>288
なぜlateinitを使うかというと「初期値というものがうまく定義できなくてうまく初期化できないから」だ
※実際にはjavaでprimitive typeであるものはnull代入できないからという理屈なのだが知らなくていい
Intとかは0とか-1とかで初期化できるだろ、最初にvarで0や-1入れとけ
Nullableもnullで初期化できるからlateinit使わずにただのvarでnull入れとけ
で、どーしても遅延初期化を使いたいなら
var value: Int by Delegates.notNull<Int>()
とか書くと形式上遅延初期化になる。むろん二度手間だが、遅延初期化という目的は一応達成される
こんなごっついことせずに素直に0とか入れておいたほうがいいんじゃねーかなと思った感覚は正しい。0入れとけ0
あとはちらっと出てたけどby lazyで
val value: Int by lazy { initValue() }
と書くことでも一応達成される。こっちだとvalで書けるので好まれることが多いみたいだね
長澤太郎の本に書いてあるけど、
lateinit は、DI(Dipendency Injection)か、ユニットテスト時か、
フレームワークが自動的に初期化すると、不都合な場合に使う
lateinit は、DI(Dipendency Injection)か、ユニットテスト時か、
フレームワークが自動的に初期化すると、不都合な場合に使う
オワコトリン
美少女仮面ポワトリン
シュシュトリアン
技術の話ができないアスペルガーがまた暴れてるのか
正直、ダジャレを理解できるのは都会人だけ。
2017年プログラミング言語アワード候補はCとKotlin
https://news.mynavi.jp/article/20171212-554317/
https://news.mynavi.jp/article/20171212-554317/
https://ideone.com/Pfncvl
これなんでデフォルト値が使用されないんですか？
これなんでデフォルト値が使用されないんですか？
>>308
デフォルト値はコンパイラが定義参照してるだけで、
型にもインスタンスにも持って無いから変数に入れた時点で使えないよ
fun f1(n: Int=1) { print(n) }
val f2 = ::f1
f1() //OK
f2() //コンパイルエラー
デフォルト値はコンパイラが定義参照してるだけで、
型にもインスタンスにも持って無いから変数に入れた時点で使えないよ
fun f1(n: Int=1) { print(n) }
val f2 = ::f1
f1() //OK
f2() //コンパイルエラー
Cが必要なレベルの仕事の割合自体は
減ってるはずなのに…謎だ
減ってるはずなのに…謎だ
Cでググってもノイズが拾われてくる率が高い
他のCと間違われてるんじゃないのか
他のCと間違われてるんじゃないのか
Cの半分はC++という時代があったからな
Cの半分はC#とC++ということでも不思議はない
C sharpならC#確定なのだが
Cの半分はC#とC++ということでも不思議はない
C sharpならC#確定なのだが
C++はcocos2dやUnrealでのゲーム開発とかあるけどCはなんだろうな
廃れることはあり得ないけど
廃れることはあり得ないけど
機械学習とかロボティクスとか自動運転とかがメディアで取り上げられるようになって学生にプログラミングへの関心がいっそう高まって教育現場での採用が増えてるのかもしれないな
就職にも有利なスキルだろうし
もともと人気の高い言語だし本格的なプログラミングの登竜門的な立ち位置の言語でもあるし
就職にも有利なスキルだろうし
もともと人気の高い言語だし本格的なプログラミングの登竜門的な立ち位置の言語でもあるし
IoTかな
(IoT)
↑
こうすると顔文字になるよね
↑
こうすると顔文字になるよね
検索エンジンで+"C programming" で検索した結果参照してるだけだからな
単にデータとしてうんこオブうんこだ
githubやstackoverflow読んでるIEEEのランキングのほうがなんぼかマシ
単にデータとしてうんこオブうんこだ
githubやstackoverflow読んでるIEEEのランキングのほうがなんぼかマシ
Javaの無名スコープを表す構文が無いことから調べていってみたけど
色々と良く設計されてると感心した
構文が無い代わりにrun関数がある
ラムダ生成コストやブロック内でのreturnが気になったけど
inline関数に渡すラムダはそれごとインライン化されるため
コストも無くreturnはちゃんと呼び出し元関数から抜ける
そうするとinlineでない関数にラムダを渡す場合のreturnとで
区別出来なくて危険かと思ったけど
inlineでないラムダではラベル無しreturnが禁止されていた
returnにラベル必須だと面倒ではと思ったけど
最後のステートメントが戻り値になる仕様だからむしろ楽だった
色々と良く設計されてると感心した
構文が無い代わりにrun関数がある
ラムダ生成コストやブロック内でのreturnが気になったけど
inline関数に渡すラムダはそれごとインライン化されるため
コストも無くreturnはちゃんと呼び出し元関数から抜ける
そうするとinlineでない関数にラムダを渡す場合のreturnとで
区別出来なくて危険かと思ったけど
inlineでないラムダではラベル無しreturnが禁止されていた
returnにラベル必須だと面倒ではと思ったけど
最後のステートメントが戻り値になる仕様だからむしろ楽だった
■Java
int f(){
{
String a = "a";
if(a.length() < 10){return 1;} // fから抜ける
}
return 2; //ここには来ない
}
■Kotlin
fun f(): Int {
run {
val a = "a"
if(a.length < 10){ return 1 } // runでなくfから抜ける
}
return 2 //ここには来ない
}
int f(){
{
String a = "a";
if(a.length() < 10){return 1;} // fから抜ける
}
return 2; //ここには来ない
}
■Kotlin
fun f(): Int {
run {
val a = "a"
if(a.length < 10){ return 1 } // runでなくfから抜ける
}
return 2 //ここには来ない
}
fun fcall(f1: () -> Int): Int = f1()
fun f(){
val a = fcall {
val a = "a"
if(a.length < 10){ return@fcall 1 } //ラベル付き
else { 2 } //returnキーワード無し
}
}
fun f(){
val a = fcall {
val a = "a"
if(a.length < 10){ return@fcall 1 } //ラベル付き
else { 2 } //returnキーワード無し
}
}
マップの値を条件判定に使いたいんだけど、Nullableをどう扱って良いのかわからない...
val map = mapOf<String,Boolean>("hoge" to false,"fuge" to true,"piyo" to false)
// ↓こんな感じで書きたいが、Nullableなので怒られる
if (map["hoge"]){/*処理*/}
//---------- 解決策 ----------
// ①強制的に!!でNotnullにする。でもなんか気持ち悪い。
if (map["hoge"]!!){/*処理*/}
// ②エルビス演算子を使う。しかし、IDEから③の書き方を提案される
if (map["hoge"] ?: false){/*処理*/}
// ③凄いバカっぽい。ていうか、これOKで一番上ダメなんだ...
if (map["hoge"] == true){/*処理*/}
なんか、どれもしっくりこない。どうするのが正解なの....
誰か教えて！お願いします！
val map = mapOf<String,Boolean>("hoge" to false,"fuge" to true,"piyo" to false)
// ↓こんな感じで書きたいが、Nullableなので怒られる
if (map["hoge"]){/*処理*/}
//---------- 解決策 ----------
// ①強制的に!!でNotnullにする。でもなんか気持ち悪い。
if (map["hoge"]!!){/*処理*/}
// ②エルビス演算子を使う。しかし、IDEから③の書き方を提案される
if (map["hoge"] ?: false){/*処理*/}
// ③凄いバカっぽい。ていうか、これOKで一番上ダメなんだ...
if (map["hoge"] == true){/*処理*/}
なんか、どれもしっくりこない。どうするのが正解なの....
誰か教えて！お願いします！
if (map.getOrDefault("hoge", false)) { ... } とか。
うーん。なんか変だね。mapOf では nullable かどうか判定しているのに get 時には nullable かどうかの情報が抜け落ちているような。
うーん。なんか変だね。mapOf では nullable かどうか判定しているのに get 時には nullable かどうかの情報が抜け落ちているような。
>>322
1はmap["hage"]とか存在しないキー指定すると落ちるだろ
2はエルビスで落ちないようになってて
3が落ちないのは、
ここ https://kotlinlang.org/docs/reference/equality.html
Structural equality あたりに書いてある仕組みのせいかな
どうmapを使えばいいのかは知らん
1はmap["hage"]とか存在しないキー指定すると落ちるだろ
2はエルビスで落ちないようになってて
3が落ちないのは、
ここ https://kotlinlang.org/docs/reference/equality.html
Structural equality あたりに書いてある仕組みのせいかな
どうmapを使えばいいのかは知らん
知らんが、kotlinみたいな言語だとキーが無いときの処理を適当にごまかすわかにはいかんだろ
>強制的に!!でNotnullにする。でもなんか気持ち悪い。
>if (map["hoge"]!!){/*処理*/}
そもそも、map は、そのキーが存在しない場合もあるのが、当たり前だろ。
そのキーが存在するかどうかを、チェックするメソッドもある
君が仕様・設計を考えるんだ。
1. そのキーが存在した場合の処理と、
2. 存在しなかった場合の処理
初心者は、強制変換の使い方をわかっていないのだから、!! を使うな
>if (map["hoge"]!!){/*処理*/}
そもそも、map は、そのキーが存在しない場合もあるのが、当たり前だろ。
そのキーが存在するかどうかを、チェックするメソッドもある
君が仕様・設計を考えるんだ。
1. そのキーが存在した場合の処理と、
2. 存在しなかった場合の処理
初心者は、強制変換の使い方をわかっていないのだから、!! を使うな
>>325
+1
「知らないキーでmapに問い合わせたときの結果はnullになることがある」問題をコード的になんとかする必要がどうしてもある
これは本当にどうしようもないので、どっかでKotlin（実際にはIDE）に知らせる面倒を許容するしかない
ポイントとしては面倒でも一旦変数にぶち込むこと。これですべてうまくいく
// checkNotNullの書き方だけ覚えればいいので最近全部これで書いてる
val mapValue: Boolean = checkNotNull(map["hoge"]){ "map does not have key:<hoge>" }
if (mapValue) { doSomething() }
// またletをそんな用途に使って
map["hoge"]?.let{ doSomething() }
// 考え方がJavaっぽい（偏見）変数に入れないとnullチェックした履歴保持できないよ
val mapValue = map["hoge"]
if (mapValue!= null && mapValue) { doSomething() }
// ほら、Kotlinの人はなんでもかんでもwhenで書きたがるから
when(map["hoge"]){
null -> println("ぬるぽ") // なくても動く
true -> doSomethingTrue()
false -> doSomethingFalse()
}
+1
「知らないキーでmapに問い合わせたときの結果はnullになることがある」問題をコード的になんとかする必要がどうしてもある
これは本当にどうしようもないので、どっかでKotlin（実際にはIDE）に知らせる面倒を許容するしかない
ポイントとしては面倒でも一旦変数にぶち込むこと。これですべてうまくいく
// checkNotNullの書き方だけ覚えればいいので最近全部これで書いてる
val mapValue: Boolean = checkNotNull(map["hoge"]){ "map does not have key:<hoge>" }
if (mapValue) { doSomething() }
// またletをそんな用途に使って
map["hoge"]?.let{ doSomething() }
// 考え方がJavaっぽい（偏見）変数に入れないとnullチェックした履歴保持できないよ
val mapValue = map["hoge"]
if (mapValue!= null && mapValue) { doSomething() }
// ほら、Kotlinの人はなんでもかんでもwhenで書きたがるから
when(map["hoge"]){
null -> println("ぬるぽ") // なくても動く
true -> doSomethingTrue()
false -> doSomethingFalse()
}
寝起きで書いたら!=がくっついた
if (mapValue != null && mapValue) { doSomething() }
まだ頭寝てるので動作チェックしてないから細かいとこは適当に直したりしてくれ
>>326
安易に nullableValue?.let{ ... } を使って欲しくないのも似たような感じ
今回で言うと現在のmapに"hoge"が登録されていることの保証はどうするんだろうと思う
ぬるぽ出ると追うのもしんどいわけでさ
1行で済むし動作にも影響らしい影響はないんだから脳死状態で checkNotNull(...){ "やべえhoge登録されてねえ" } とか書いとくのおすすめしたいわ
if (mapValue != null && mapValue) { doSomething() }
まだ頭寝てるので動作チェックしてないから細かいとこは適当に直したりしてくれ
>>326
安易に nullableValue?.let{ ... } を使って欲しくないのも似たような感じ
今回で言うと現在のmapに"hoge"が登録されていることの保証はどうするんだろうと思う
ぬるぽ出ると追うのもしんどいわけでさ
1行で済むし動作にも影響らしい影響はないんだから脳死状態で checkNotNull(...){ "やべえhoge登録されてねえ" } とか書いとくのおすすめしたいわ
map, hash は、集合の概念だから、
集合A に属するか属さないか、のどちらかの状態をとる
1. そのキーが集合A にあれば、値が取得できる
2. そのキーが集合A になければ、値が取得できない
1, 2 で、君がどういう処理をするか、仕様・設計を決めるのは君！
集合A に属するか属さないか、のどちらかの状態をとる
1. そのキーが集合A にあれば、値が取得できる
2. そのキーが集合A になければ、値が取得できない
1, 2 で、君がどういう処理をするか、仕様・設計を決めるのは君！
③がバカっぽいと感じるのは
真偽値 == 真偽値 だと勘違いしているから
実際には２つのNullableTypeの等値比較
真偽値 == 真偽値 だと勘違いしているから
実際には２つのNullableTypeの等値比較
if(map.getValue("hoge")){/* 処理 */}
これで基本的にキーが存在しないと例外に行くしシンプルだね
これで基本的にキーが存在しないと例外に行くしシンプルだね
直感的にはおかしく感じるな。(最初結果見た時は驚いたw)
https://paiza.io/projects/zLCe3AYlPO9luQp7z2NaIw
しかしクラスの参照同士の比較なのでこれで良い。
https://paiza.io/projects/zLCe3AYlPO9luQp7z2NaIw
しかしクラスの参照同士の比較なのでこれで良い。
>>333
おかしく感じたのはprintln("True")と書いたからじゃないの
not False と True は同義でないよ
https://paiza.io/projects/1WgctVAqXu8SWmlIYtx4YA
おかしく感じたのはprintln("True")と書いたからじゃないの
not False と True は同義でないよ
https://paiza.io/projects/1WgctVAqXu8SWmlIYtx4YA
おまえがそう思うのならそうなのだろう。おまえの中ではな。
>>333
リンク先のコード消えてるよ
同じ接続元・同じURLで開くと変更モードになるようだから
「新規コード」を押してから扱わないといけない
リンク先のコード消えてるよ
同じ接続元・同じURLで開くと変更モードになるようだから
「新規コード」を押してから扱わないといけない
>>340
ごめん。うっかりしていた。
で、書き直してグレードアップしたよ。
https://paiza.io/projects/KX6WsUduUz1OoV0sEOwyTw
ごめん。うっかりしていた。
で、書き直してグレードアップしたよ。
https://paiza.io/projects/KX6WsUduUz1OoV0sEOwyTw
糞みてえな言語だな
Xamarin程の糞はない
糞だからこそ良い
やはりJavaを超えられなかったか。
＼ ∩─ｰ､ ====
＼／ ● ､_ ｀ヽ ======
/ ＼( ● ● |つ
| X_入__ノ ミ そんな餌で俺様が釣られクマ――
､ (＿／ ノ /⌒l
/＼＿＿＿ノﾞ＿/ / =====
〈 ＿_ノ ====
＼ ＼＿ ＼
＼＿__） ＼ ====== (´⌒
＼ ＿＿_ ＼＿＿ (´⌒;;(´⌒;;
＼＿＿＿）＿＿＿）(´;;⌒ (´⌒;; ズザザザ
＼／ ● ､_ ｀ヽ ======
/ ＼( ● ● |つ
| X_入__ノ ミ そんな餌で俺様が釣られクマ――
､ (＿／ ノ /⌒l
/＼＿＿＿ノﾞ＿/ / =====
〈 ＿_ノ ====
＼ ＼＿ ＼
＼＿__） ＼ ====== (´⌒
＼ ＿＿_ ＼＿＿ (´⌒;;(´⌒;;
＼＿＿＿）＿＿＿）(´;;⌒ (´⌒;; ズザザザ
購入者の確認不足や品切れ時にたまたま買われることを狙った有名な詐欺だよ
classのdelegateってinterfaceしか出来ないみたいだけど、
classやabstractのインスタンスでdelegateできない理由をご存知の方いらっしゃいますでしょうか。
可: class SubClass(instance: Interface) : Interface by instance
不可: class SubClass(instance: SuperClass) : SuperClass by instance
classやabstractのインスタンスでdelegateできない理由をご存知の方いらっしゃいますでしょうか。
可: class SubClass(instance: Interface) : Interface by instance
不可: class SubClass(instance: SuperClass) : SuperClass by instance
もちろんSuperClassはopen指定してあります。
>>352 に答えられる人にそんな野暮なこと言う方はいないと思いますが念のため。
In Actionには「インターフェースを実装しいているなら〜」とさらっと書いていて
クラスでdelegateできない理由は触れられていませんでした。
>>352 に答えられる人にそんな野暮なこと言う方はいないと思いますが念のため。
In Actionには「インターフェースを実装しいているなら〜」とさらっと書いていて
クラスでdelegateできない理由は触れられていませんでした。
androidにdelegateなんて言葉はない
>>352-353
例えばこんな感じのKotlinコードをJavaへ変換してみればわかる
interface Interface1 { ... }
interface Interface2 { ... }
class SubClass (impl1:Interface1, impl2:Interface2) : Interface1 by impl1, Interface2 by impl2
例えばこんな感じのKotlinコードをJavaへ変換してみればわかる
interface Interface1 { ... }
interface Interface2 { ... }
class SubClass (impl1:Interface1, impl2:Interface2) : Interface1 by impl1, Interface2 by impl2
>>355 ありがとうございます。
interface Interface1 { ... } が
open class Interface1 { ... } であったとしても、
class SubClass extends Interface1 implements Interface2
になるので、支障ないと思うのですが、どこか勘違いしていますでしょうか。
interface Interface1 { ... } が
open class Interface1 { ... } であったとしても、
class SubClass extends Interface1 implements Interface2
になるので、支障ないと思うのですが、どこか勘違いしていますでしょうか。
>>356
ごめん多重継承は関係無かったね
問題になるのはコンストラクタかな
class SubClass extends SuperClass というJavaコードに相当するものに変換されるからには
SuperClass のコンストラクタを呼ぶ必要があるけど、
でも SuperClass by instance によってインスタンスが別に渡されたらSuperClassの実体が二つになってしまう
ごめん多重継承は関係無かったね
問題になるのはコンストラクタかな
class SubClass extends SuperClass というJavaコードに相当するものに変換されるからには
SuperClass のコンストラクタを呼ぶ必要があるけど、
でも SuperClass by instance によってインスタンスが別に渡されたらSuperClassの実体が二つになってしまう
>>352
インターフェースでないと移譲が保証出来ないからでは
インターフェースと違ってクラスの場合はそれが持つオーバーライド可能なメンバ全て移譲しても移譲になるとは限らない
例えば、あるライブラリがInterface, SuperClass, それらを引数に取る関数を提供しているとする
Interfaceを受け取るならInterfaceとして扱うべき
（内部の実装クラスへダウンキャスト出来ること等を前提とすべきでない）で、
SuperClassを受け取る場合も同様だが
こちらはprivateメンバへのアクセスなども含まれていてそれは移譲出来ない
インターフェースでないと移譲が保証出来ないからでは
インターフェースと違ってクラスの場合はそれが持つオーバーライド可能なメンバ全て移譲しても移譲になるとは限らない
例えば、あるライブラリがInterface, SuperClass, それらを引数に取る関数を提供しているとする
Interfaceを受け取るならInterfaceとして扱うべき
（内部の実装クラスへダウンキャスト出来ること等を前提とすべきでない）で、
SuperClassを受け取る場合も同様だが
こちらはprivateメンバへのアクセスなども含まれていてそれは移譲出来ない
>>352
abstractやclassじゃextendsになっちゃうじゃん
したいのはimplementsじゃん
だからOnly interfaces can be delegated toって言われちゃうんだよ
abstractやclassじゃextendsになっちゃうじゃん
したいのはimplementsじゃん
だからOnly interfaces can be delegated toって言われちゃうんだよ
>>357の言いたかったこととは違うかもしれませんが、以下のように理解しました。
KotlinのdelegateはIn ActionではCollectionを引き合いに出しているが、
実際には、実装したクラスのコンストラクタがprivateで、
ヘルパークラスのファクトリメソッドを通じてしかインスタンスを生成できない
ようなケースで力を発揮する。
コンストラクタがpublicでopenなclassやabstractの場合、素直に継承することを想定している。
In Actionの例も(共変とか反変とかを抜きにすれば)実はArrayListの継承で解決できる。
逆に、classでのdelegateを認めるとfinalなclassも継承できてしまい、
これを禁止するために規則を増やすことになる。
>>359
書き込んだ動機としては、多数のプロパティを持ったクラスを継承したい時に、
class SuperClass(val comp1: Comp1, val com2: Comp2, ...)
class SubClass(instance: SuperClass) : SuperClass(instance.comp1, instance.comp2,...)
とすると、かなり宣言が不格好になるので、
class SubClass(instance: SuperClass) : SuperClass by instance
としたかったのです。
>>358
SuperClass内のSuperClassを引数に取る関数は、
SubClassにおいても引数としてSuperClassを渡せば正しく動作するので、
private(あるいはprotected)メンバへのアクセスがなくても、
実装可能でないかと思います。
ご指摘で理解できていない点があればご指摘いただければ幸いです。
皆様ありがとうございました。
KotlinのdelegateはIn ActionではCollectionを引き合いに出しているが、
実際には、実装したクラスのコンストラクタがprivateで、
ヘルパークラスのファクトリメソッドを通じてしかインスタンスを生成できない
ようなケースで力を発揮する。
コンストラクタがpublicでopenなclassやabstractの場合、素直に継承することを想定している。
In Actionの例も(共変とか反変とかを抜きにすれば)実はArrayListの継承で解決できる。
逆に、classでのdelegateを認めるとfinalなclassも継承できてしまい、
これを禁止するために規則を増やすことになる。
>>359
書き込んだ動機としては、多数のプロパティを持ったクラスを継承したい時に、
class SuperClass(val comp1: Comp1, val com2: Comp2, ...)
class SubClass(instance: SuperClass) : SuperClass(instance.comp1, instance.comp2,...)
とすると、かなり宣言が不格好になるので、
class SubClass(instance: SuperClass) : SuperClass by instance
としたかったのです。
>>358
SuperClass内のSuperClassを引数に取る関数は、
SubClassにおいても引数としてSuperClassを渡せば正しく動作するので、
private(あるいはprotected)メンバへのアクセスがなくても、
実装可能でないかと思います。
ご指摘で理解できていない点があればご指摘いただければ幸いです。
皆様ありがとうございました。
interface InterfaceClazz{
val comp1:Any
var comp2:Any
fun method1()
}
class SuperClazz(override val comp1: Any, override var comp2: Any) :InterfaceClazz {
override fun method1() {
println("SuperClazz.method1 comp1:$comp1 comp2:$comp2")
}
}
class SubClazz(instance:SuperClazz):InterfaceClazz by instance
こういうのじゃだめなの？
val comp1:Any
var comp2:Any
fun method1()
}
class SuperClazz(override val comp1: Any, override var comp2: Any) :InterfaceClazz {
override fun method1() {
println("SuperClazz.method1 comp1:$comp1 comp2:$comp2")
}
}
class SubClazz(instance:SuperClazz):InterfaceClazz by instance
こういうのじゃだめなの？
>>361
自分が作ったクラスの場合ならそうできることは考えましたが、
他人がinterfaceを定義せずに作ったクラスでやりたい場合どうすればいいんだろうという疑問でした。
自分が作ったクラスの場合ならそうできることは考えましたが、
他人がinterfaceを定義せずに作ったクラスでやりたい場合どうすればいいんだろうという疑問でした。
Java, C# が、interface を作った理由は、
C++ のclass の、ひし形の形になる、ダイヤモンド継承を嫌ったから
ほとんどの言語は、単一継承 + interface。
継承チェーンに、同じクラスが現れると困る
親クラス ← 子クラス1・2 ← 孫クラス
孫クラスが、子クラス1・2を多重継承すると、
両方の子クラス部分に、親クラスのメンバ変数を含んでしまう
孫クラスからすると、どちらの子クラス経由で、
親クラスのメンバ変数にアクセスすべきか、ややこしい
だから多重継承用に、メンバ変数を持たず、メソッドだけを持つ、interface が作られた
is-a・class・継承よりも、has-a・interface・委譲の方が、柔軟性があって好まれる
C++ のclass の、ひし形の形になる、ダイヤモンド継承を嫌ったから
ほとんどの言語は、単一継承 + interface。
継承チェーンに、同じクラスが現れると困る
親クラス ← 子クラス1・2 ← 孫クラス
孫クラスが、子クラス1・2を多重継承すると、
両方の子クラス部分に、親クラスのメンバ変数を含んでしまう
孫クラスからすると、どちらの子クラス経由で、
親クラスのメンバ変数にアクセスすべきか、ややこしい
だから多重継承用に、メンバ変数を持たず、メソッドだけを持つ、interface が作られた
is-a・class・継承よりも、has-a・interface・委譲の方が、柔軟性があって好まれる
複数のinterfaceでメソッド名が被ってたらどうするの？
そんな事態見たことないけど確かにどうなるんだ？
パッケージ名とinterface名で指定するんじゃね
Delegataion ってなんだ・・・Delegation ね
coroutine builderの例えばasyncの定義を見ると、
fun <T> async(
context: CoroutineContext = DefaultDispatcher,
start: CoroutineStart = CoroutineStart.DEFAULT,
parent: Job? = null,
block: suspend CoroutineScope.() -> T
): Deferred<T> (source)
ってなってんですが、blockパラメータの型が関数型になっているのですが、
型の前にCoroutieScope.とかついてるのですが、これはなんなんでしょうか？？
fun <T> async(
context: CoroutineContext = DefaultDispatcher,
start: CoroutineStart = CoroutineStart.DEFAULT,
parent: Job? = null,
block: suspend CoroutineScope.() -> T
): Deferred<T> (source)
ってなってんですが、blockパラメータの型が関数型になっているのですが、
型の前にCoroutieScope.とかついてるのですが、これはなんなんでしょうか？？
>>370
block内でのthisがその型のインスタンスになる
例
https://ideone.com/KsS26N
block内でのthisがその型のインスタンスになる
例
https://ideone.com/KsS26N
>>371
ありがとうございます。
うーん。ややこしい。何のためにこんなのが必要なんだ・・
呼び出される関数の方でもインスタンス(val a = A("aa"))を作って
関数を呼び出さないといけないってことですよね。
ありがとうございます。
うーん。ややこしい。何のためにこんなのが必要なんだ・・
呼び出される関数の方でもインスタンス(val a = A("aa"))を作って
関数を呼び出さないといけないってことですよね。
delegateってパフォーマンス悪かったりします?
>>361のような方法を試したら、目に見えて遅くなりました。
もっとも他にも色々いじった後だから、他が原因の可能性もありますが....。
>>361のような方法を試したら、目に見えて遅くなりました。
もっとも他にも色々いじった後だから、他が原因の可能性もありますが....。
仕組み的に体感出来る程の劣化は起きないと思う
エルビス式のエルビスって何ですか？プレスリーしか出てこないんですけど
と思ってググったら本当にプレスリー由来だったのね、、
>>375
調べてみたら、delegateよりも前に速度低下はあったようでした。ありがとうございました。
調べてみたら、delegateよりも前に速度低下はあったようでした。ありがとうございました。
?: これのどこがプレスリーなんだよ？と思った時の脳内に浮かんでいたのはサタデーナイトフィーバーの人だったのは俺だけだろうな
？：）
?が5
>>161だけど
Javaのリリースサイクルが6か月ごとになったので2018/3/20リリース予定
http://openjdk.java.net/projects/jdk/10/
ローカル変数の型推論きたー
後はGoogleさん早めにAndroidで使えるように。
Javaのリリースサイクルが6か月ごとになったので2018/3/20リリース予定
http://openjdk.java.net/projects/jdk/10/
ローカル変数の型推論きたー
後はGoogleさん早めにAndroidで使えるように。
後はkotlinを使ってみて自分的にうらやましのは
・Null safety
・１ファイルに複数のクラス書ける
・コルーチン
ぐらいかな・・
・Null safety
・１ファイルに複数のクラス書ける
・コルーチン
ぐらいかな・・
俺は
・val
・最後の引数のラムダを括弧の外に書けること
・「==」でnull考慮込みのequals()呼び出しにしてくれること
・val
・最後の引数のラムダを括弧の外に書けること
・「==」でnull考慮込みのequals()呼び出しにしてくれること
とにかくJavaと同じことをするのに記述量が圧倒的に少なくて済むのが良いわ。
一つ一つはそれこそ数行程度の違いになるけど、チリが積もって最終的にかなり短くなって可読性が段違い
一つ一つはそれこそ数行程度の違いになるけど、チリが積もって最終的にかなり短くなって可読性が段違い
Sから始まる某言語と違って何故か読みやすい
Smalltalkの悪口はやめろ
俺のS言語が・・・
SQL
Objective-Cを経験すれば大抵の言語は涙が出るほど読みやすい
Schemeの悪口？
perl「せやな」
そういえば Objective-C ってMacとかiOSで使われてるんだっけ？
MacとかiOSでしか使われていない
SwiftはiOSでしか使われていない
いくらいい言語でも林檎様の傘下だと何されるかわからんからな
使えねーわ
使えねーわ
swiftってオープンソースじゃなかったっけ？
Swiftはオープンソース化以降は言語開発もコミュニティベースで行われてる
頑張ってはいるようだけどいくつかの問題でObjCに戻る人も割と居るし
クロスプラットフォーム系との競合もあって人気は減少傾向
頑張ってはいるようだけどいくつかの問題でObjCに戻る人も割と居るし
クロスプラットフォーム系との競合もあって人気は減少傾向
Kotlinの方がよくできてる
Kotlinでのクロスプラットフォームは Kotlin/Native(まだベータ) と Multi-OS Engine があるけど
UI部分が固有になるから React NativeのKotlin版のような
UIブリッジするライブラリが生まれてほしい
WebViewも手だけど
UI部分が固有になるから React NativeのKotlin版のような
UIブリッジするライブラリが生まれてほしい
WebViewも手だけど
JavaScriptエンジンを挟みたくない
C#でええやん
コミュニティの条件に収まらなくてサブスクリプションが要る都合でそっちは二の足
言語自体は割と好きだけど
言語自体は割と好きだけど
何年か前はiOSとandroidのクロスプラットフォーム開発はいまいちすぎて結局それぞれネイティブて開発したけど、今はどうなんだろうな
最近スマホアプリさわらんからよくわからん
最近スマホアプリさわらんからよくわからん
あ、そうだ。iOSやMacの開発にKotlin使えれば全て丸く収まるじゃねえか。
MacだけならJREあるから既に動くのかな？
MacだけならJREあるから既に動くのかな？
Android studioはMac版もあるし当然Kotlinも使える
ただ、iPhoneアプリは作れねぇ
ただ、iPhoneアプリは作れねぇ
>>406
MacとiOSはMacが無いとコンパイルすら出来ないって糞みたいな仕様が一番のネックだからな
MacとiOSはMacが無いとコンパイルすら出来ないって糞みたいな仕様が一番のネックだからな
Windowsもネイティブアプリはそうだろ？ 違うっけ？
クロスプラットフォームは糞
Xamarin C#が正解
ちょまど教の狂信者か
Xamarin程の糞はない
C#も10年前の時代遅れの言語だし圧倒的にswift,Java,Kotlinの方が人気が高いし求人も多い
VS for Macはgitでブランチを切り替えたりするだけでビルドできなくなって、
クリーン、リビルド、ＩＤＥ再起動、ＰＣ再起動を頻繁に繰り返さないといけなくなる欠陥品なのが糞
大体MicrosoftはWindowsPhoneのシェアを二桁取ってからモノを言えと言いたい
MicrosoftがやっていることはGoogleやAppleの作ったパイを横取りしようとしているだけ
MVVM前提の開発環境とか言うくせに外部ライブラリを入れないと良い感じでMVVMできないのが糞
ＵＩは共通化できると言うわりにListViewは重くてスワイプがもたついたり画像の表示が遅かったりするのが糞
Xamarin.Formsはちょっと複雑なことしようとするとお得意のdependency serviceとcustom rendererの連発
クロスプラットフォームと言うならXamarin.Formsだけでできないことを恥じろよ
WebViewなどXamarin.Formsの提供するUI部品が糞すぎて
一旦Xamarin.Formsの提供する機能で実装して糞な思いをさせられた後で
Xamarin.AndroidとXamarin.iOSで計3回も同じ実装をさせられるのが糞
Xamarinなんてマイナーな環境使っている人が少ないせいでググって調べものするのに時間がかかるのが糞
qiitaやstackoverflowの情報もXamarinに関するものはAndroidの10分の1以下の投稿しかなくて
下手すると解決策が見つからなくてデザインや機能の面で妥協する結果となる
任天堂のXamarin製アプリもカブドットコムのXamarin製アプリも星平均3.0の糞アプリ認定されてる
MicrosoftのAndroid向けedgeブラウザもXamarin製でなく、
Microsoft自身も糞認定して使わない糞開発環境がXamarin
エンジニアもデザイナーもお客さんも全員がっかりするのがXamarin
結論としてXamarinを使うと開発工数は伸びアプリのクオリティは落ちるということ
XamarinをやっているやつというのはC#の機能を使うことやXamarinを使うことそれ自体が目的化していて
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために
行われることであるべきで、完全に自分本位でゴミを量産し続けるXamarinエンジニアは全員死んだ方が良い
C#も10年前の時代遅れの言語だし圧倒的にswift,Java,Kotlinの方が人気が高いし求人も多い
VS for Macはgitでブランチを切り替えたりするだけでビルドできなくなって、
クリーン、リビルド、ＩＤＥ再起動、ＰＣ再起動を頻繁に繰り返さないといけなくなる欠陥品なのが糞
大体MicrosoftはWindowsPhoneのシェアを二桁取ってからモノを言えと言いたい
MicrosoftがやっていることはGoogleやAppleの作ったパイを横取りしようとしているだけ
MVVM前提の開発環境とか言うくせに外部ライブラリを入れないと良い感じでMVVMできないのが糞
ＵＩは共通化できると言うわりにListViewは重くてスワイプがもたついたり画像の表示が遅かったりするのが糞
Xamarin.Formsはちょっと複雑なことしようとするとお得意のdependency serviceとcustom rendererの連発
クロスプラットフォームと言うならXamarin.Formsだけでできないことを恥じろよ
WebViewなどXamarin.Formsの提供するUI部品が糞すぎて
一旦Xamarin.Formsの提供する機能で実装して糞な思いをさせられた後で
Xamarin.AndroidとXamarin.iOSで計3回も同じ実装をさせられるのが糞
Xamarinなんてマイナーな環境使っている人が少ないせいでググって調べものするのに時間がかかるのが糞
qiitaやstackoverflowの情報もXamarinに関するものはAndroidの10分の1以下の投稿しかなくて
下手すると解決策が見つからなくてデザインや機能の面で妥協する結果となる
任天堂のXamarin製アプリもカブドットコムのXamarin製アプリも星平均3.0の糞アプリ認定されてる
MicrosoftのAndroid向けedgeブラウザもXamarin製でなく、
Microsoft自身も糞認定して使わない糞開発環境がXamarin
エンジニアもデザイナーもお客さんも全員がっかりするのがXamarin
結論としてXamarinを使うと開発工数は伸びアプリのクオリティは落ちるということ
XamarinをやっているやつというのはC#の機能を使うことやXamarinを使うことそれ自体が目的化していて
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために
行われることであるべきで、完全に自分本位でゴミを量産し続けるXamarinエンジニアは全員死んだ方が良い
参考
Android・iOS対応のクロスプラットフォームライブラリ、Intel Multi-OS Engine(MOE)
https://qiita.com/yyYank/items/2d96640d713a527691be
Kotlin/Nativeを使ってiOSアプリを作ってみる
https://qiita.com/noripi/items/4ee969c48b3da5ca6fbd
Android・iOS対応のクロスプラットフォームライブラリ、Intel Multi-OS Engine(MOE)
https://qiita.com/yyYank/items/2d96640d713a527691be
Kotlin/Nativeを使ってiOSアプリを作ってみる
https://qiita.com/noripi/items/4ee969c48b3da5ca6fbd
面倒くさそう
>>418
面倒なら
・SwiftやObjective-Cで直に作る
・Cordovaなどで作る
・iPhoneアプリは諦める
詳細は該当のスレでどうぞ
面倒なら
・SwiftやObjective-Cで直に作る
・Cordovaなどで作る
・iPhoneアプリは諦める
詳細は該当のスレでどうぞ
>>417
こんなんあるのか、知らなかった。試してみるよありがとう。
ただクロスプラットフォームのライブラリって大体最終的にうまくいかないから、つい警戒してしまうw
こんなんあるのか、知らなかった。試してみるよありがとう。
ただクロスプラットフォームのライブラリって大体最終的にうまくいかないから、つい警戒してしまうw
Xamarin C#が正解だよ
簡単で高品質
簡単で高品質
時間掛かって低品質のアプリが出来上がるだけクロスプラットフォーム
正式セミナーで技術より人脈なんて宣伝する糞プラットフォームは使わない
Xamarinは簡単だけど高品質かと言われると、、
実際クロスプラットフォームが最適なアプリってそんな多くないよな。
何かの画像処理をするとかそういう端末内で複雑なビジネスロジックを組まなくちゃいけないものならそこを共通化できるメリットはあるだろうけど、
サーバーサイドと通信して何かをするのがメインなクライアント系アプリなら普通にネイティブで2つ作った方が楽
何かの画像処理をするとかそういう端末内で複雑なビジネスロジックを組まなくちゃいけないものならそこを共通化できるメリットはあるだろうけど、
サーバーサイドと通信して何かをするのがメインなクライアント系アプリなら普通にネイティブで2つ作った方が楽
Unityでええやん
APIクライアントやちょっとした処理も完全に共通化できるから便利だよXamarin
Java,Kotlin / Swift,obj-cだと日付型と日付操作apiみたいな些細な部分でも違いがある
C#にすると文法や基本ライブラリの粒度で共通化できる
Java,Kotlin / Swift,obj-cだと日付型と日付操作apiみたいな些細な部分でも違いがある
C#にすると文法や基本ライブラリの粒度で共通化できる
C++使いなら、QTとかSDLとか
Xamarinみたいな糞はプロトタイプ開発でしか使い道ない
まともなアプリはみんなネイティブ
任天堂のXamarin製アプリもカブドットコムのXamarin製アプリも星平均3.0の糞アプリ認定されてる
Microsoft自身も糞認定して使わない糞開発環境がXamarin
まともなアプリはみんなネイティブ
任天堂のXamarin製アプリもカブドットコムのXamarin製アプリも星平均3.0の糞アプリ認定されてる
Microsoft自身も糞認定して使わない糞開発環境がXamarin
Unityは日本語入力の問題さえ解決すれば多分かなりの部分の解決になると思う。
なんせ画面を描くところから自力でやってるからな。
業務アプリでもポチポチ画面押すだけの物とか結構いけると思うし、実際あるんじゃないかな。
なんせ画面を描くところから自力でやってるからな。
業務アプリでもポチポチ画面押すだけの物とか結構いけると思うし、実際あるんじゃないかな。
共通部分はともかくUiはそのプラットフォームのネイティブでやったほうが結局は簡単なんだよな
どのプラットフォームでもネイティヴで書いてもVとVMは普通に分離するだろ
なんでマルチプラットフォーム対応で追加のコストはかからない
なんでマルチプラットフォーム対応で追加のコストはかからない
>>430
おう業務アプリと入力フォーム部品の蜜月性なめんあ
Unityはゲームと家庭向けアプリ特化の方向性のままでいいと思うぞ
おう業務アプリと入力フォーム部品の蜜月性なめんあ
Unityはゲームと家庭向けアプリ特化の方向性のままでいいと思うぞ
クロプラは凝ったことしようとすると詰むね
Xamarin程の糞はない
>>433
確かにそうか。
社内カレンダー通りの休日がマークされる日付選択とか、営業日入力とか色々あるもんな。
確かにそうか。
社内カレンダー通りの休日がマークされる日付選択とか、営業日入力とか色々あるもんな。
ザマァw
Xamarinで全てが解決する
ざまりんは座間市のマスコットキャラクターです
ざまりんとことりん・・・りん繋がりか
クマリンだと税金までとってくれる
今更だけど、ことりんとこっとりんどっちが正しいんだろ
XamarinをやっているやつというのはC#の機能を使うことやXamarinを使うことそれ自体が目的化していて
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために
行われることであるべきで、完全に自分本位でゴミを量産し続けるXamarinエンジニアは全員死んだ方が良い
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために
行われることであるべきで、完全に自分本位でゴミを量産し続けるXamarinエンジニアは全員死んだ方が良い
ことりんの記述の簡潔さが良いと言われているスレに来てC#書けなんて言われたらそりゃ嫌がらせだよ
C#の方がエレガントなコードを書けるでしょ
エレガントで保守性の高いプログラムはお客にとってもありがたい
お客にいいものを届けたいならXamarinだよ
Kotlinの奇形じみたセンスのない文法はお客も辟易してる
kotlinを使いたいというプログラマのわがままでお客に迷惑をかけちゃダメだ
エレガントで保守性の高いプログラムはお客にとってもありがたい
お客にいいものを届けたいならXamarinだよ
Kotlinの奇形じみたセンスのない文法はお客も辟易してる
kotlinを使いたいというプログラマのわがままでお客に迷惑をかけちゃダメだ
なんか変なのが居着いちゃったな。。。
C#は、.Net か Monoを入れないといけないのがウザいし
JavaやKotlinは、JDK入れないといけないし、
やっぱそういう意味では、Swiftが最強やな
JavaやKotlinは、JDK入れないといけないし、
やっぱそういう意味では、Swiftが最強やな
ねーよ
ことりんスレということを思い出していただきたい
何ここ、ザマリンスレなの？
ザマリンアンチが居ついた
Xamarinスレでは相手にされないものでね
ここなら最初からできる
ここなら最初からできる
うーん。しかし、Xamarin って本屋行くとiOSアプリ関係の本の所にちょっとしか置いてないし、
ほとんど名前しか知らないから俺には批判することすらできないなあ。眼中にない感じ。
仕事でも必要になることは今のところ全くないし。(ま、仕事で使わないと言えば Kotlin も
Java も俺は使わないんだけどね)。
ほとんど名前しか知らないから俺には批判することすらできないなあ。眼中にない感じ。
仕事でも必要になることは今のところ全くないし。(ま、仕事で使わないと言えば Kotlin も
Java も俺は使わないんだけどね)。
Xamarinに興味ないのならこのスレ来んなよカス
Xamarin程の糞はない
お前らそんなに暇ならKotlinで人の役に立つブラグラムでも書いてこいよ
やだよ
俺は俺のためにプログラムするだけだ
俺は俺のためにプログラムするだけだ
ことりんはBカップ、ザマリンはHカップだそうだ。
どっちが優れているかは明らかだろう。
どっちが優れているかは明らかだろう。
ザマリンはケツぷりんぷりんやで
ことりん使いはロリコンってことなのか？
まぁ、そういうことになるわな
女性の敵ですよ（歌詞）
ある非同期関数を呼び出し側のコンテキストで実行したいのですが、例えばC#の場合
void async testAsync() {
await funAsync1(); // configureAwait(false)しない
hoge1();
await funAsync2(); // configureAwait(false)しない
hoeg2();
}
で、testAsyncをメインスレッドから呼び出しせば、hoge1とhoge2は呼び出し側のコンテキストつまり
メインスレッド上で実行されるのですが、
同じ事をkotlinでやるにはどうすればいいでしょうか？？
fun testAsync() : Job {
return launch {
funAsync1().await()
hoge1();
funAsync2().await()
hoge2();
}
}
void async testAsync() {
await funAsync1(); // configureAwait(false)しない
hoge1();
await funAsync2(); // configureAwait(false)しない
hoeg2();
}
で、testAsyncをメインスレッドから呼び出しせば、hoge1とhoge2は呼び出し側のコンテキストつまり
メインスレッド上で実行されるのですが、
同じ事をkotlinでやるにはどうすればいいでしょうか？？
fun testAsync() : Job {
return launch {
funAsync1().await()
hoge1();
funAsync2().await()
hoge2();
}
}
launch(UI)とか昔のコードみるとあるのですが、UIは廃止されたのでしょうか？
ここXamarinスレだから、そんなこと聞かれても困る
なんかスレチな話題ばっかりなんだが、コトリンインアクション買う価値ある？
本家HPのリファレンスで十分？
本家HPのリファレンスで十分？
>>473
わからない。それは今のお前の状態によって変わる。立ち読みして自分で決めろ。
まあしかし俺のエスパー能力を使った直観によれば、多分買った方が良い。
わからない。それは今のお前の状態によって変わる。立ち読みして自分で決めろ。
まあしかし俺のエスパー能力を使った直観によれば、多分買った方が良い。
launch(UI)のUIはcoroutine-androidの別モジュールだった。すみません。
コルーチンは実験的らしいけど
Androidなら「android kotlin 非同期」とかでググってみたらいいんじゃないかな
実験的じゃない方なら「android 非同期」でJavaのやり方をそのままKotlinに
Androidなら「android kotlin 非同期」とかでググってみたらいいんじゃないかな
実験的じゃない方なら「android 非同期」でJavaのやり方をそのままKotlinに
>>473-474
Kotlinイン・アクション、2017
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016
太郎はたぶん、イン・アクションを参考にしながら、スタートブックを書いたのかな？
そういう意味では、太郎本の方が有利
Kotlinイン・アクション、2017
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016
太郎はたぶん、イン・アクションを参考にしながら、スタートブックを書いたのかな？
そういう意味では、太郎本の方が有利
コルーチンっていつまで実験的扱いなんだ
普通に十分実用に耐えるんだが
普通に十分実用に耐えるんだが
>>478
サンクス
じゃー、様子見するよ
立ち読みしろって言われても近くにでかい本屋ねーし、4000円越えで無駄に高いしな
サンクス
じゃー、様子見するよ
立ち読みしろって言われても近くにでかい本屋ねーし、4000円越えで無駄に高いしな
標準でページ翻訳を備えるブラウザが便利
stackoverflow(英語本家)のやり取りなんかは本じゃ得られないし
stackoverflow(英語本家)のやり取りなんかは本じゃ得られないし
ノン・アクション
Amazonでkindle版のサンプルがただで読めるよ。サンプルだからどの程度まで読めるかはわからないが。
Stackoverflowを翻訳なしで読めないならKotlinより先に英語を勉強した方が良いと思う
煽りじゃなくてマジで
煽りじゃなくてマジで
全く読めないならその通りだね
その場合検索もまともに出来ないだろうし
でも情報を探しているときに日本語と同じ速度で流し読み出来る人以外には翻訳おすすめ
その場合検索もまともに出来ないだろうし
でも情報を探しているときに日本語と同じ速度で流し読み出来る人以外には翻訳おすすめ
Google先生の翻訳精度も最近上がってる気がする
たまにできる・できないとか真逆の意味で訳される
読めなくても文法の基礎知識があれば翻訳を修正しながら読める
最近のGoogle先生はほんと優秀で、一回全部Google翻訳にかけて、意味がわからんところだけ英文見て修正するだけでも単語調べる時間減るから、だいぶ時間の節約になる
精度が良いからって頼りきりなのは問題だよ
データシートも翻訳するの？
データシートも翻訳するの？
時間節約や翻訳支援に有用性があるという程度の話に
突っかかって行く意味あるのか？
突っかかって行く意味あるのか？
言語オタクと初心者以外本なんて必要ないような
最低限の知識は軽く公式のドキュメント読んで後は
その都度覚えれば十分だなぁ
言語オタクじゃないので言語よりアプリ作るのが目的だからな
最低限の知識は軽く公式のドキュメント読んで後は
その都度覚えれば十分だなぁ
言語オタクじゃないので言語よりアプリ作るのが目的だからな
Kotlin自体より、Android SDK等のクラスライブラリの方が使いこなすの大変だわ
新しい言語覚える時は適当に評価高い本を一冊買う派だな俺は
全体像をつかむのに体系的ににまとまった本はやっぱり便利
全体像をつかむのに体系的ににまとまった本はやっぱり便利
自分の慣れた言語で当たり前だったやり方でも、他の言語ならもっとスマートに書けるとかあるからな
公式ドキュメントだとどうしても全体を俯瞰的に見るのは難しいから、自分が存在を知っている情報以外の情報に気付きにくい
公式ドキュメントだとどうしても全体を俯瞰的に見るのは難しいから、自分が存在を知っている情報以外の情報に気付きにくい
カンファレンス楽しみ
ねえ
// int[] sKey
// byte[] wKey
// int data
wKey[0] += sKey[(int) wKey[1] & 0xFF] - data;
wKey[1] -= (byte) ((sKey[(int) data & 0xFF] ^ wKey[2]) & 0xFF);
wKey[2] ^= (byte) (data + sKey[(int) wKey[3] & 0xFF]) & 0xFF;
wKey[3] -= (byte) (wKey[0] - sKey[(int) data & 0xFF]) & 0xFF;
int dKey = ((int) wKey[0]) & 0xFF | (wKey[1] << 8) & 0xFF00 | (wKey[2] << 16) & 0xFF0000 | (wKey[3] << 24) & 0xFF000000;
こういうのってKotlinでどう書けばいいの…
// int[] sKey
// byte[] wKey
// int data
wKey[0] += sKey[(int) wKey[1] & 0xFF] - data;
wKey[1] -= (byte) ((sKey[(int) data & 0xFF] ^ wKey[2]) & 0xFF);
wKey[2] ^= (byte) (data + sKey[(int) wKey[3] & 0xFF]) & 0xFF;
wKey[3] -= (byte) (wKey[0] - sKey[(int) data & 0xFF]) & 0xFF;
int dKey = ((int) wKey[0]) & 0xFF | (wKey[1] << 8) & 0xFF00 | (wKey[2] << 16) & 0xFF0000 | (wKey[3] << 24) & 0xFF000000;
こういうのってKotlinでどう書けばいいの…
宿題は自分でやろうね
>>497
言いたいことを想像しながらの答えになるけど、ビット演算もシフト演算もKotlinにはあるよ。
http://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-int/index.html
Cのような見栄えにならないとしても、それはKotlinの目指すところではないということかと。
言いたいことを想像しながらの答えになるけど、ビット演算もシフト演算もKotlinにはあるよ。
http://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-int/index.html
Cのような見栄えにならないとしても、それはKotlinの目指すところではないということかと。
kotlinでやるならwKeyもIntArrayとかにしたほうがよさそう
普通にJavaでしょ
殆どIntelliJがやってくれる
殆どIntelliJがやってくれる
>>497
IntelliJでunko.ktというファイルを作る
そのコードをそのまま貼り付ける
終わり
IntelliJでunko.ktというファイルを作る
そのコードをそのまま貼り付ける
終わり
もとの言語知らんけどもっとマシな書き方あるだろと思う
何かの外部の処理論理をそのまま記述したって感じだな
外部の処理記述と突き合わせなければならないような場合はこんなのをよく見る
変にスマートに書き換えされてると脳内再変換コストがかかるというパターンｗ
外部の処理記述と突き合わせなければならないような場合はこんなのをよく見る
変にスマートに書き換えされてると脳内再変換コストがかかるというパターンｗ
>>507
Javaではこれがfalseになる
Integer a = 0;
Long b = a + 0L;
System.out.println( a.equals(b) );
コード上のプリミティブ型とクラス型の区別を排除していたり（最適化でプリミティブ型になる）
型推論を持つKotlinで数値型の暗黙の型変換は地雷になるのであえて無くしている
Javaではこれがfalseになる
Integer a = 0;
Long b = a + 0L;
System.out.println( a.equals(b) );
コード上のプリミティブ型とクラス型の区別を排除していたり（最適化でプリミティブ型になる）
型推論を持つKotlinで数値型の暗黙の型変換は地雷になるのであえて無くしている
こういうの見るとセンスねえなあって思う
C#の開発者が優秀すぎた
C#の開発者が優秀すぎた
Javaの検査例外になれるとKotlin-JVMで検査例外使えないのが辛い・・
>>508
例えば引数にByteを使う場合にJavaでは数値の明示的変換が要るのに対してKotlinでは要らないけど
いざ数値と比較しようとするときには
-> Java/Kotlin
== -> true/error
==(cast) -> true/true
equals -> false/false
equals(cast) -> true/true
になってKotlin側は値比較をしてくれないのはそのせいか
いやでも引数に使うときや代入時には(型の範囲内なら)変換無しで通るんだから
数値比較でも比較される型の範囲内ならキャスト不要にして欲しいな
例えば引数にByteを使う場合にJavaでは数値の明示的変換が要るのに対してKotlinでは要らないけど
いざ数値と比較しようとするときには
-> Java/Kotlin
== -> true/error
==(cast) -> true/true
equals -> false/false
equals(cast) -> true/true
になってKotlin側は値比較をしてくれないのはそのせいか
いやでも引数に使うときや代入時には(型の範囲内なら)変換無しで通るんだから
数値比較でも比較される型の範囲内ならキャスト不要にして欲しいな
kotlin初心者の質問くんはここでいいですか…？
ほかあたってください
すみませんでした
すみません、Xamarinスレと勘違いしました
ワロタ
kotlinの話題が許されないkotlinスレ
何言ってんだここはザマリンスレだぞ
そういや Kotlin も初心者質問スレみたいのがあった方が良いんじゃないか?
今はまだ言語そのものを知らない人が多いようなのでこのスレだけでも良いかも知れないが、何れ増えて来るだろうし。
今はまだ言語そのものを知らない人が多いようなのでこのスレだけでも良いかも知れないが、何れ増えて来るだろうし。
そんなん増えてきたら作ればいいだろ
このスレですら過疎すぎてxamarinに乗っ取られてるんだからこれ以上住人を分散させなくていい
このスレですら過疎すぎてxamarinに乗っ取られてるんだからこれ以上住人を分散させなくていい
Xamarin程の糞はない
ある
XamarinってKotlinより流行ってるん?
結局Xamarinの話題でまわるスレ
Kotlinはようやく存在が知られ始めたところだし、これからよ
ざまりんとかことりんとか何か気安いな
XamarinというかC#が強すぎるんだよね
いやしかし特定の分野でだけではないかな。Web関係とか。
少なくとも俺の日頃の仕事では全く絡まないのでどこでよく使われているのかよくわからない。
少なくとも俺の日頃の仕事では全く絡まないのでどこでよく使われているのかよくわからない。
C++でAndroid書くみたいなのは完全にオワコン？
ニッチコン
え？
Xamarinって確かライセンス買わないと使える機能に制限あるんじゃなかったっけ
使った事がないのでわかりません
そうか Java VMで動くC#があれば全て解決するのか
C#自体あんまり好きじゃないから勘弁してくれ
>>535
XamarinのライセンスはVisual Studioライセンスに統合されてる
Communityライセンスの条件内なら無料
そうでなければ年間サブスクリプションが必要（約6万円 / 年・開発者）
XamarinのライセンスはVisual Studioライセンスに統合されてる
Communityライセンスの条件内なら無料
そうでなければ年間サブスクリプションが必要（約6万円 / 年・開発者）
安いなぁ
安いと感じるか高いと感じるかはあなたしだいです。
でここはKotlinスレでいいんだよな？
Kotlin だって
いいじゃないか
JavaVM だもの
いいじゃないか
JavaVM だもの
>>537
.NET上で動くJVMならあるけど(実用に耐えるとは言っていない)。
http://www.ikvm.net/index.html
.NET上で動くJVMならあるけど(実用に耐えるとは言っていない)。
http://www.ikvm.net/index.html
kotlinは好きだけどJVMがなぁ・・・
て思ってる人はかなり多いと思うよ
kotlin nativeに頑張ってもらって
さっさとJVMから足洗ってほしい
て思ってる人はかなり多いと思うよ
kotlin nativeに頑張ってもらって
さっさとJVMから足洗ってほしい
同意
ぼきはJavaのライブラリ使うのでJVMでもいいれす(^p^）
俺もとりあえずはJVMで良い。
気になるのはJavaScriptの方かな。
気になるのはJavaScriptの方かな。
Kotlinに移行しようかとしばらく触ってみたけど、C#の方が痒いところに手が届くいい言語だな、、、
なんだかんだで膨大のJavaのライブラリとそれらのノウハウを使えるってのが大きいわな
Javaの腐ったライブラリよりC#の洗練されたライブラリの方が有り難いんだけど
ほとんど借金なんだよなぁ
COBOLと同じ道辿ってる
COBOLと同じ道辿ってる
イミフ
JAVAの肩持つわけじゃないがCOBOLと同じ道は流石にないわ
COBOLとは全然状況違うよな
分散処理のフレームワークとかミドルとか活発に開発されてるし
言語としては最先端ではないかもしれないけど、逆に最先端の言語でも優れたプロダクトを生み出してないなら大して存在価値ないし
分散処理のフレームワークとかミドルとか活発に開発されてるし
言語としては最先端ではないかもしれないけど、逆に最先端の言語でも優れたプロダクトを生み出してないなら大して存在価値ないし
これから終わるんだよ
kotlinとc#に駆逐される
kotlinとc#に駆逐される
JavaVMの上でCOBOLが動くようになったりして･･･
一定の奴隷需要は残るだろうね
これから終わると言われ続けて10年
write once run anywhereとか言われてた頃が懐かしいな
>>560
いつだか覚えていないくらい昔にマジメにそれを開発しようとしてた会社があったような
COBOLしか書けないおじさんを救済するためだけの代物ですぐ頓挫したけど
いつだか覚えていないくらい昔にマジメにそれを開発しようとしてた会社があったような
COBOLしか書けないおじさんを救済するためだけの代物ですぐ頓挫したけど
まあでも確かにJava言語は使われなくなっていくだろうね。
うちもJavaで作ってるシステムの機能追加なんかはkotlinでやってるし、JVMで動かすのが要件な新規のプログラムももうほぼkotlinに移行してる。
スマホは知らんけどandroid開発はもうkotlinが多いのかな？
うちもJavaで作ってるシステムの機能追加なんかはkotlinでやってるし、JVMで動かすのが要件な新規のプログラムももうほぼkotlinに移行してる。
スマホは知らんけどandroid開発はもうkotlinが多いのかな？
ドロイド会議のアンケートでもkotlin使ってるひと多かったし
Kotlinを推しつつもJavaはまだ現役だと考えている
しかしJava8でラムダが入ったときと
AndroidがJava8に対応したときは正直「余計なことしおって」と思ったな
Java6のままだったら今以上にKotlinが推されてただろうからｗ
しかしJava8でラムダが入ったときと
AndroidがJava8に対応したときは正直「余計なことしおって」と思ったな
Java6のままだったら今以上にKotlinが推されてただろうからｗ
しかしJavaのラムダはやりすぎだろって感じがした。
確かに
レガシーJavaおじさんと現代人Kotlin使いで棲みわけた方が平和だったかもしれないね
レガシーJavaおじさんと現代人Kotlin使いで棲みわけた方が平和だったかもしれないね
kotlinでandroidの説明してるところなんか全然ない
先進的な一部が勝手に使い始めてるだけで普及の段階ではない、いつもながら日本は遅れてる
先進的な一部が勝手に使い始めてるだけで普及の段階ではない、いつもながら日本は遅れてる
全然ないことはないだろ
(僕の周りでは)全然ない
(国内では)全然ない
(国内では)全然ない
最近ネットに出て来るandroid周りのサンプルはほぼkotlinじゃない？
kotlinの実務経験ないやつは失業ざまあｗｗｗ
実務経験って、そもそも実務で使われてる所がまだ少なかろう。
実際DroidKaigiのセッションスライドのコードはほぼKotlinだったし、実務もKotilnである割合はかなり増えてるでしょ。
自分も実務ではもう1年くらい使ってるし。
自分も実務ではもう1年くらい使ってるし。
そりゃAndroidだから増えてて当然な感じするが、世の中にはAndroidしかないわけではないからなあ。
俺は逆にandroidまったくやらんけどkotlinめっちゃ使ってるよ
ローカルのプログラムでもサーバーサイドでも
まだこういうのは少数派だろうけど
ローカルのプログラムでもサーバーサイドでも
まだこういうのは少数派だろうけど
ああ。俺は趣味では使うよ。というか学習中なので敢えて使う感じ。Kotlinだとどう書けるかを調べながら書いてる感じ。
ながら勉強？
ながらというか、CやPerlなら仕事で何十年も使ってて間が働くからどう書くかはすぐ想像できる(Javaも趣味で20年ぐらいやってるのでなんとなくわかる)んだが、
Kotlinはそれと似たようにも書けるしKotlinならではの書き方もできるわけで、その辺のKpylin的な書き方を学習してる感じ。
Kotlinはそれと似たようにも書けるしKotlinならではの書き方もできるわけで、その辺のKpylin的な書き方を学習してる感じ。
間がじゃない、勘がだ。
うう。やはりスマホだと変なタイプミス増えるな。orz
くぴりんｗ
どうせお前らrxもMVVMもfluxも分からないんだろ
失業ざまああｗｗｗｗｗｗｗ
失業ざまああｗｗｗｗｗｗｗ
どこかで聞いたことがあるようなないような・・・
俺
も
知らない
も
知らない
車輪の
再発明に
名前を付けた
再発明に
名前を付けた
モルゲッソヨ
今分かったんですけど、プライマリコンストラクタ宣言せずに
セカンダリコンストラクタって宣言できるんですね。
プライマリコンストラクタの主な用途ってコンストラクタのパラメータの宣言とプロパティの宣言を
一緒にできるぐらいですか？？用途は。
class Test(val p1: String)とか
セカンダリコンストラクタって宣言できるんですね。
プライマリコンストラクタの主な用途ってコンストラクタのパラメータの宣言とプロパティの宣言を
一緒にできるぐらいですか？？用途は。
class Test(val p1: String)とか
>>593
中身が空っぽなだけで、プライマリコンストラクタは常にあるよ
https://ideone.com/tSGMPY
中身が空っぽなだけで、プライマリコンストラクタは常にあるよ
https://ideone.com/tSGMPY
基本は省略表記なだけ
https://ideone.com/3Uc2dJ
https://ideone.com/3Uc2dJ
>>594
でも、空のプライマリコンストラクタを明示的に宣言するのと省略するのでは厳密には同一ではないですよね？？
だから、言葉の定義の問題にもなっちゃうけど、initブロックはinitブロックであってプライマリコンストラクタと同一視
しない方がいいとか。プライマリコンストラクタはあくまでclass Test(val p1: String)のval p1: String部分だけで、
プライマリコンストラクタはボディは持てない。
初期化はinitブロックで行うとか？
でも、空のプライマリコンストラクタを明示的に宣言するのと省略するのでは厳密には同一ではないですよね？？
だから、言葉の定義の問題にもなっちゃうけど、initブロックはinitブロックであってプライマリコンストラクタと同一視
しない方がいいとか。プライマリコンストラクタはあくまでclass Test(val p1: String)のval p1: String部分だけで、
プライマリコンストラクタはボディは持てない。
初期化はinitブロックで行うとか？
https://kotlinlang.org/docs/reference/classes.html
正式な言語仕様書とかないんでしったけ？？
JavaとかC#はしっかりした言語仕様書みたいのあって言葉もしっかり定義されてると
思いますが、kotlinはそういうのないとか・・
正式な言語仕様書とかないんでしったけ？？
JavaとかC#はしっかりした言語仕様書みたいのあって言葉もしっかり定義されてると
思いますが、kotlinはそういうのないとか・・
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
まぁ、ここにはプライマリコンストラクタの一部になるって書いてあるね。
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
まぁ、ここにはプライマリコンストラクタの一部になるって書いてあるね。
>>596
そうね暗黙の場合と違いあるから省略という表現は不正確だったごめん
セカンダリコンストラクタが無い場合、暗黙のプライマリコンストラクタはpublicになる
セカンダリコンストラクタが有る場合、暗黙のプライマリコンストラクタは未初期化メンバを残せる
そうね暗黙の場合と違いあるから省略という表現は不正確だったごめん
セカンダリコンストラクタが無い場合、暗黙のプライマリコンストラクタはpublicになる
セカンダリコンストラクタが有る場合、暗黙のプライマリコンストラクタは未初期化メンバを残せる
>>597
明らかにまだ未完成だけどこれだと思う
http://jetbrains.github.io/kotlin-spec/
明らかにまだ未完成だけどこれだと思う
http://jetbrains.github.io/kotlin-spec/
Kotlin使いがJava使いにマウント取ってる様を見てまたこの繰り返しかと思いそっ閉じ
マウント取ってるように見える？そりゃなんていうか、劣等感強すぎでは？
てか一々そんなこと考えてないで自分でも使えばいいじゃん。禁止されているわけでもなし。
Java が使える状態になったことのある人が Kotlin 使えるようになれないわけがないと思うが。
てか一々そんなこと考えてないで自分でも使えばいいじゃん。禁止されているわけでもなし。
Java が使える状態になったことのある人が Kotlin 使えるようになれないわけがないと思うが。
ていうかkotlin使いって99%Java使いも兼ねてるだろうからマウントとるも何もないのでは
今使ってる人はそもそもJavaできるからな
より使いやすくても、対立構造にはならないよな
より使いやすくても、対立構造にはならないよな
>>557
モバイル開発は違うかもだが、業務系は極端に言っちまうとjava要員集めるっつたら使い捨て兵隊集めだよ。
モバイル開発は違うかもだが、業務系は極端に言っちまうとjava要員集めるっつたら使い捨て兵隊集めだよ。
そんな自分の知ってる世界だけの狭い話をされても
Kotlin, RxJava, MVVMは基本的な必須スキルだからな
未だに実務経験ないやつは失業確定ざまああｗｗｗｗｗｗｗ
未だに実務経験ないやつは失業確定ざまああｗｗｗｗｗｗｗ
Android系の技術スレは失業だの兵隊だの低いところでマウント争ってるんだな。稼いでるやついなそう。
そういやKotlinはまだ求人数は少ないけど給与は良いって調査結果があったな
中途半端だと仕事にありつけないかもしれないな
中途半端だと仕事にありつけないかもしれないな
しかしKotlinってKotlinらしくない従来のJavaっぽい書き方をしても動いてしまうからな。金を多く払う意味があまりないかも知れないぞ。
Kotlinで単価が高いのは、チームが今後Kotlinでやってけるように導入の面倒見れる人だよ
>>611が言ってるレベルの奴なんてそもそも高い単価で雇われないから
>>611が言ってるレベルの奴なんてそもそも高い単価で雇われないから
面倒みなきゃならんほどのものじゃないでしょ
プログラム初心者じゃあるまいし
プログラム初心者じゃあるまいし
>>614
確認だけど職業としてプログラマやってる人たちの話って前提だよね？
小学校のプログラムの授業とかじゃなくて
確認だけど職業としてプログラマやってる人たちの話って前提だよね？
小学校のプログラムの授業とかじゃなくて
>>616
もういいよめんどくさい
じゃあKotlinできればそのレベルに関わらず誰でも単価高いってことでええわ
もういいよめんどくさい
じゃあKotlinできればそのレベルに関わらず誰でも単価高いってことでええわ
ラムダ式から式の外側のthisを参照するにはどうすればいいでしょうか？現状、
val this_ = this
async {
this_
}
とかしてますけど、これ以外方法ない？
val this_ = this
async {
this_
}
とかしてますけど、これ以外方法ない？
>>618
無いことはないけど俺もそうしてるよ
class A {
fun f(){
async {
this@A
}
}
}
https://kotlinlang.org/docs/reference/this-expressions.html
無いことはないけど俺もそうしてるよ
class A {
fun f(){
async {
this@A
}
}
}
https://kotlinlang.org/docs/reference/this-expressions.html
言っとくけどselfもダサいよ
そうじゃねえだろ
それを言うなら、self_ もダサい
それを言うなら、self_ もダサい
やっぱ thiz だよね
どう書いても最適化されて同じコードになったりして･･･
俺なら一目で何だか分かる名前にする
例えば？
ore,kore,sore
val 式の外側のthis = this
async {
式の外側のthis.method()
}
これが1番わかりやすいな
async {
式の外側のthis.method()
}
これが1番わかりやすいな
class名.instanceはコトリンではつかえないのん？
>>631
objectで宣言したクラス(シングルトン)のclass名.INSTANCEのことでしょうか?
objectで宣言したクラス(シングルトン)のclass名.INSTANCEのことでしょうか?
エンクロージングインスタンスの話。
クラス名.thisの間違いだった。
クラス名.thisの間違いだった。
ラムダに束縛したいのはthisだけとは限らないしネストも有り得るので
クラス外の関数として分離した場合の引数名のイメージで変数名付けてる
val view = this
val cal = activeCalculator
async {
cal.recalc()
transaction {
val tran = this
check(cal, tran)
}
view.notifyUpdate()
}
クラス外の関数として分離した場合の引数名のイメージで変数名付けてる
val view = this
val cal = activeCalculator
async {
cal.recalc()
transaction {
val tran = this
check(cal, tran)
}
view.notifyUpdate()
}
ネストする時は、
this__
this___
this____
this_____
と、_を増やしてけば
this__
this___
this____
this_____
と、_を増やしてけば
よみづらい
ま、しかし、あまりにもネストが深くなるようならロジック考え直した方が良いかも
メソッド参照とか別クラスとか。
ネストは三段ぐらいまでにしといた方がいいだろうな。
その辺が迷宮の入り口だ。
Cのポインタとかも同じ。3段以上先には魔物が住んでいる。
その辺が迷宮の入り口だ。
Cのポインタとかも同じ。3段以上先には魔物が住んでいる。
せめて他のメソッドに切り出すくらいは最低でもやるべきだわな
androidでデータバインディングしようとして
class Foo {
@Bindable
val bar get() = hoge.bar
}
とかできないの？？・・・
class Foo {
@Bindable
val bar get() = hoge.bar
}
とかできないの？？・・・
エラー内容はThis annotation is not applicable to target 'member property without
backingField or delegate'です。
どうしたらいいでしょかね
backingField or delegate'です。
どうしたらいいでしょかね
Javaでは
class Foo {
@Bindable
String getBar() { hoge.getBar() }
}
で、hogeはFooのフィールド変数です。
class Foo {
@Bindable
String getBar() { hoge.getBar() }
}
で、hogeはFooのフィールド変数です。
ごめんさい。解決しました。@get:Bindable
また、アノテーションだけど。遅延初期化ではアノテーションつけれんの？しょぼーん。
@field:Transient
val lazyVal by lazy {}
だめか・・
@field:Transient
val lazyVal by lazy {}
だめか・・
いま触れてないけどkotlin-Nativeってどんな感じ？
ほとんどなんでもコンパイルかけれる？
見たところLLVM通すから行けそうだけど
ほとんどなんでもコンパイルかけれる？
見たところLLVM通すから行けそうだけど
実用で使うのはまだ怖いけど、遊びで触る分にはちゃんと動くよ。
javaの標準パッケージが全く使えないから、jvmで動かす前提で作ってあるクラスだのライブラリだのが動かないという辛さはある。
javaの標準パッケージが全く使えないから、jvmで動かす前提で作ってあるクラスだのライブラリだのが動かないという辛さはある。
javaのパッケージ使えないんならわざわざJVM言語使う価値なんかないわｗさよなら～
うん。はっきり言って現状ではこれを使うメリットが何一つ思い浮かばないよ俺も。
地味にアップデートされてるからJBが飽きなければそのうち実用レベルになるかもねえ
それなりの標準ライブラリはあるんでしょ？まだないの？(ないわけないか。なければ Hello world も出せないもんな)
ありがとう。
なるほどまだ様子見しとくわ
Javaの標準パッケージ動かないの辛いね
なるほどまだ様子見しとくわ
Javaの標準パッケージ動かないの辛いね
この言語意味不明になってきた。
class Test {
var str: String
get() = field
set(value) { }
constructor() {
str = "あいう"
}
}
val t = Test()
普通にstrがnullになる
class Test {
var str: String
get() = field
set(value) { }
constructor() {
str = "あいう"
}
}
val t = Test()
普通にstrがnullになる
セカンダリコンストラクタでstrのbakcingFieldにアクセスできないの？？
constructor() {
str = "あいう" // これはsetter経由のプロパティアクセス
}
constructor() {
str = "あいう" // これはsetter経由のプロパティアクセス
}
>>661
意図はないけど、null安全とかいっておきながらkotlin側だけでnull入るコード書けるのまずいような気がする。
いや、プロパティの初期化方法がうざくて色々調べてたら気づいただけ。
意図はないけど、null安全とかいっておきながらkotlin側だけでnull入るコード書けるのまずいような気がする。
いや、プロパティの初期化方法がうざくて色々調べてたら気づいただけ。
そういうことね
確かにこれならsetterの部分でコンパイルエラー出て欲しい気がするな
帰ったらドキュメント舐め回してみるか
確かにこれならsetterの部分でコンパイルエラー出て欲しい気がするな
帰ったらドキュメント舐め回してみるか
>>658
lateinintつけないでコンパイル通ってしまうなら、Kotlinコンパイラのバグの可能性も...
lateinintつけないでコンパイル通ってしまうなら、Kotlinコンパイラのバグの可能性も...
悪意の無い初心者がめちゃくちゃ書いてもちゃんと面倒見てくれるべきだと思う
null安全の導入とともに変数は宣言時に初期値を与えなきゃいけなくなって、
ローカル変数は宣言時に与えなきゃいけないけど、インスタンス変数は宣言時または
コンストラクタ内で与えればOKなんだけど、
backingFieldを持つプロパティと相性悪かった？ってことかな。
backingFieldを持つプロパティはプロパティイニシャライザを与えるか、
コンストラクタ内でbackingFieldに直接初期化するという条件を付けくわえないとだめ？
field:str = "あいう" // コンストラクタ内でのみ使えるbakckingFieldにアクセスする専用構文の導入が必要 か
str = "あいう” // コンストラクタ内でのプロパティへの代入はsetterは経由しないとかの条件が必要
ローカル変数は宣言時に与えなきゃいけないけど、インスタンス変数は宣言時または
コンストラクタ内で与えればOKなんだけど、
backingFieldを持つプロパティと相性悪かった？ってことかな。
backingFieldを持つプロパティはプロパティイニシャライザを与えるか、
コンストラクタ内でbackingFieldに直接初期化するという条件を付けくわえないとだめ？
field:str = "あいう" // コンストラクタ内でのみ使えるbakckingFieldにアクセスする専用構文の導入が必要 か
str = "あいう” // コンストラクタ内でのプロパティへの代入はsetterは経由しないとかの条件が必要
バグ相当だと思う
初期化(setter呼び出し)の有無は判定出来ているのだから
コンパイルエラーにするのが難しいなら
その直後にそのプロパティのBacking Fieldがnullだったら
KotlinNullPointerExceptionを投げる処理を暗黙的に追加すべき
初期化(setter呼び出し)の有無は判定出来ているのだから
コンパイルエラーにするのが難しいなら
その直後にそのプロパティのBacking Fieldがnullだったら
KotlinNullPointerExceptionを投げる処理を暗黙的に追加すべき
コンパイラor言語仕様のバグって意味ね
null安全の導入->非nullableのクラス型のデフォルト値なんてないから、変数は必ず初期化する
必要がある->(この再、nullable、非nullable関係なく全変数初期化するように)
未初期化の変数がコンパイラエラーにならないんて、これが言語仕様なら
仕様がクソだったってことだな(さすが、適当に作った言語ってことに)。
コンパイラのバグであることを祈ろう。
必要がある->(この再、nullable、非nullable関係なく全変数初期化するように)
未初期化の変数がコンパイラエラーにならないんて、これが言語仕様なら
仕様がクソだったってことだな(さすが、適当に作った言語ってことに)。
コンパイラのバグであることを祈ろう。
>>673
の一つ目は勘違いでした。
Kotlinは便利だけど、いくつかの規則は言語仕様でなく契約に基づいていて
契約違反のコードは勘違いを起こさざるを得ないと言い訳する...orz
の一つ目は勘違いでした。
Kotlinは便利だけど、いくつかの規則は言語仕様でなく契約に基づいていて
契約違反のコードは勘違いを起こさざるを得ないと言い訳する...orz
C#でいいじゃん
一回しか代入したくないならセッターの中にそういう処理を書けばいいだけだし、
非NullableなのにNullが入る状態でコンパイルできるのはどう考えてもバグでしょ
非NullableなのにNullが入る状態でコンパイルできるのはどう考えてもバグでしょ
>>673
そういう手法のときは内部フィールド側はNullableになっているべきじゃないかな
通常ケースの一つとしてnullがあるパターンなわけだから
private var strF: String? = null
var str: String get(){return strF ?: ""} set(value) { }
そういう手法のときは内部フィールド側はNullableになっているべきじゃないかな
通常ケースの一つとしてnullがあるパターンなわけだから
private var strF: String? = null
var str: String get(){return strF ?: ""} set(value) { }
setterを空にしたらバッキングフィールドへの代入は永遠にされないのでは？
外部からバッキングフィールドへの代入ってできないよね？
(getterで値を変更するカウンターみたいなやつは別として)。
外部からバッキングフィールドへの代入ってできないよね？
(getterで値を変更するカウンターみたいなやつは別として)。
Nullableでないプロパティのsetterがnullの状態で呼ばれることがあるって考えるとなんか気持ち悪いな
俺の感覚だとsetterが呼ばれた時点でフィールドは初期化されていて欲しいしフィールドの初期化にsetterは使って欲しくない
俺の感覚だとsetterが呼ばれた時点でフィールドは初期化されていて欲しいしフィールドの初期化にsetterは使って欲しくない
JRubyよりはええんか？
>>658の var str : String の部分を var str = "aaa" みたいに書くと var なのに str に何を代入しても
中身が"abc"のまま変化しないプロパティが完成w
中身が"abc"のまま変化しないプロパティが完成w
間違えた。"abc"じゃない"aaa"な。
>>682
ワロタ
嫌な会社を辞めるときにテロとしてそういうコード残しておくイタズラとかできそう
それはそうとnullableじゃないのにnullになりうるセッターがコンパイル通るのはやっぱおかしいよな
そんなんする奴がいるのかって話ではあるが
ワロタ
嫌な会社を辞めるときにテロとしてそういうコード残しておくイタズラとかできそう
それはそうとnullableじゃないのにnullになりうるセッターがコンパイル通るのはやっぱおかしいよな
そんなんする奴がいるのかって話ではあるが
githubにあるkotlinのプロジェクトはissuesのリンクがないや
どこに報告すればいいんだ
どこに報告すればいいんだ
こりゃダメだ
C#使おっと
C#使おっと
C#はそもそもnull安全じゃないから出てくること自体おかしい
8.0ではoptinでnull安全にできるようになるんじゃなかったけ。まあ、でもmicrosoftはこんなポカしないと思うけど。
オプティン…
・セカンダリコンストラクタが存在する
・代入して初期化してる(ように見える)プライマリコンストラクタかセカンダリコンストラクタがある
この2つを満たすとコンパイル通っちゃうのかな
https://paiza.io/projects/78ZAW5fM_jNEyfhRPD5VbA
・代入して初期化してる(ように見える)プライマリコンストラクタかセカンダリコンストラクタがある
この2つを満たすとコンパイル通っちゃうのかな
https://paiza.io/projects/78ZAW5fM_jNEyfhRPD5VbA
完全に趣味でSwift触り始めたんだけど、ことりんと似すぎてて脳の切り替えが大変
setterがNOPだからでしょ
何もおかしくないと思うんだが
何もおかしくないと思うんだが
あー、ごめんごめん、nullableじゃないのにってことね
SwiftではOptionalよん
そこら辺の名称も統一してくれたらよかったのに
引数や戻り値の属性(アノテーション)としての出自でNullable (@Nullable)
型引数を持つデータ構造として出自でOptional (Optional<T>)
型引数を持つデータ構造として出自でOptional (Optional<T>)
だから何？
単なる経緯にだからも何も無いんだけど
Optionalではアンラップが必要で、Nullableでは不要
つまりOptionalは神Nullableは糞
間違えた逆だNullableは神Optionalは糞
神と糞は種類が違うだろ
Xamarin程の糞はない
Kotlinではnullにならない型など存在しないのだ、がっはっは
神は糞である。
糞は紙で拭け
Kotlinインアクションの尼評価低いなと思ったら理由が「難しい」ってw
やっぱGroovy in Actionだろ、GradleはGrooovyなんだぜぇ
こんな本が出てたんだな。
Androidアプリ開発の教科書
http://amzn.asia/59lxVwl
Androidアプリ開発の教科書
http://amzn.asia/59lxVwl
あ、Kotlin で検索したら出てきた本だけど Kotlin とは限らないみたいだな。すまん。
すまん。Kotlin の K の字も出てこないな。忘れてくれ。
Kotlinイン・アクション、2017
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016
せっかく太郎が、イン・アクションを参考にして、わかりやすく書いたのだから、
日本人は、太郎本を読んだ方がよい
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016
せっかく太郎が、イン・アクションを参考にして、わかりやすく書いたのだから、
日本人は、太郎本を読んだ方がよい
情報量はインアクションの方が多いから、わざわざ薄めた本を買う必要なんてないよ
Kotlin本といえば今のところインアクションとスタートブックの２択だと思うけど、
「難しい」って理由でレビュー評価下げるのはどうよ？と思ったんで、難しい以外に
インアクションで問題点ある？
バージョンが古いとか？
「難しい」って理由でレビュー評価下げるのはどうよ？と思ったんで、難しい以外に
インアクションで問題点ある？
バージョンが古いとか？
※716
Androidの入門本なんてAndroid搭載機種の種類と同じくらい大量に出てるのになぜわざわざそれを貼ろうと思ったのか
Androidの入門本なんてAndroid搭載機種の種類と同じくらい大量に出てるのになぜわざわざそれを貼ろうと思ったのか
電子書籍でレイアウト固定だと買う気しない
知らんけどkotlinのandroid入門書なんてもう山ほど出てるんちゃうの？まだjavaばっかなの？
まだ一冊しかないのでは？
そうなのか、意外と動き遅いんだな
本で勉強する時代じゃないからね
細切れ情報を探すのはやだな。レベルも方針もバラバラだし。
良書があるなら本がいい。
良書があるなら本がいい。
まあ、AndroidでKotlin使うのは増え続けるだろうから何れ本も増えるだろう。
本は中古やで何冊かあったよ、まだ高かったけど
正直Pythonは失敗だったと思う
正直Pythonは失敗だったと思う
pythonは糞本で良書が埋もれちゃってる
Null Objectパターン流行るといいなあ。
Null Objectはgof外でしょ
気にするな、禊としてXamarinのライセンス買ってこい
買わない買わない
>>721
本を読んだけどどっちもよかったよ。
ただ読み手のスキルで理解力に差があるからそこで評価が分かれてるのかも。
本を読んだけどどっちもよかったよ。
ただ読み手のスキルで理解力に差があるからそこで評価が分かれてるのかも。
IntelliJの変換機能使ってシコシコKotlinに変換してるけどstatic無いのがウザくなって来た
Swiftにはあるのにー
Swiftにはあるのにー
自動変換使ったら普通にcompanion objectにならなかったっけ
スーパーコンパニオンがいいです
自動変換してもコンパニオンにならなかったから、シコシコ変えてる
Android stuiosって糞重いのな
Xcodeの比じゃなかったわ
Xcodeの比じゃなかったわ
Core i7、メモリ32GBだけど、コーディングに支障があるほど重いとは感じないかな
ノート用のi5、8Gでもサクサク動くぞ
基本xcodeの方が重くない？
Android stuios...
明らかにxcodeの方が重い
あ、Android StudioじゃなくてAndroid stuiosの話なのか
それなら知らんわ
それなら知らんわ
VisualStudioはサクサク動くね
Android Studioはエミュレータの起動が激重
お前のPCが糞なんだろ
そういやエミュレータは遅いな。あれ速くならんもんかね？実機に繋いじゃうしかないか？
そんなにおもいか？
その部分はXcodeも糞重いからまあしゃあない
お前の収入がまともなPCも買えないほど低いだけ
Flutterが話題になってるけど、Dartなんだよなあ、、
Kotlinならよかったのに
やっぱ金掛けてゲーミングPCにしないといかんかね
何の話ししてるんだ
IntelliJファミリーのIDEが不自然に重い時はプラグインを疑った方が良い
もしくは単純にindexingか何かをしてるだけか
とりあえず2013年モデルでメモリ8GBのMBPでもサクサク動く
もしくは単純にindexingか何かをしてるだけか
とりあえず2013年モデルでメモリ8GBのMBPでもサクサク動く
さっさとまともな収入得られる会社に転職しろ
googleさんの本命はkotlinじゃなくてflutterのDartだったってこと?
いや、あの会社がプログラミング言語を開発するのは趣味みたいなもんだから。
飽きたら捨てるでしょ
女ったらし
Goってどこ行ったんだよ
トイレ
有名どころだけでもGASとgoとDartとあるからな
統一しろや
統一しろや
なんかgoogleって統一感無いよなー。
dart捨てたと思ってたのに、このタイミングで復活させるとかさ。ならchromeに予定通りvm載せろや
dart捨てたと思ってたのに、このタイミングで復活させるとかさ。ならchromeに予定通りvm載せろや
もうどれにも移行せずJavaに留まるのが一番
>>773
それが望ましいな。まぁ、Flutter+Dartが成功したらchromeにもDartVM搭載復活とかあるかもね。
それで、JavaScript絶滅に追いやってほしいわ。
今どきの言語ならなんえり好みしないからフロントエンドからJavaScriptを絶滅に追いやってほしい。
それが望ましいな。まぁ、Flutter+Dartが成功したらchromeにもDartVM搭載復活とかあるかもね。
それで、JavaScript絶滅に追いやってほしいわ。
今どきの言語ならなんえり好みしないからフロントエンドからJavaScriptを絶滅に追いやってほしい。
未だにKotlinの実務経験のないやつは完全失業ざまあｗｗｗ
それはない
つか、あれ、ラムダ式の中で値返すときretrunとかキーワードつけないのかー
ふーんって思ったけど、制御までreturnするんじゃないのか・・
{
if (条件式) 値1
その他の文
値2
}
で、if文の条件式が真の時、値1が返ってreturnするのかと思ったらその後も実行されるのか・・
ふーんって思ったけど、制御までreturnするんじゃないのか・・
{
if (条件式) 値1
その他の文
値2
}
で、if文の条件式が真の時、値1が返ってreturnするのかと思ったらその後も実行されるのか・・
あれ、どうやって値返すんだよん。if else使いたくないんだけど。
コンパイルエラーがでるからそこらへん適当にやっててもなんとかなったけどww。
真面目に考えるとどうなってんだこれww
今までコンパイルエラーが消えるように適当に例えば、
fun testAsync(): Deffered<String> {
return async {
lock.withLock {
"ABC"
}
}
}
むしろ、retrunを付けると怒られたからこのままにしたけど。return@asyncってラベルつけるればいいのか。
ラベルつけない場合はどうなってんだこれ。
真面目に考えるとどうなってんだこれww
今までコンパイルエラーが消えるように適当に例えば、
fun testAsync(): Deffered<String> {
return async {
lock.withLock {
"ABC"
}
}
}
むしろ、retrunを付けると怒られたからこのままにしたけど。return@asyncってラベルつけるればいいのか。
ラベルつけない場合はどうなってんだこれ。
inline の場合は return の意味がちょっと変わっちゃうんじゃない?
>>785
ありがとう。ちょっと前に話題になってたのね。
つか、前に教えてもらったhttp://jetbrains.github.io/kotlin-spec/
にそれに関する事のってねぇな？
DartだってECMAでしっかりした仕様書になってるのに、
仕様書がいまだにこんなレベルなのにAndroidのFirst Class Languageにするなんて
Google何考えてんだか・・
ありがとう。ちょっと前に話題になってたのね。
つか、前に教えてもらったhttp://jetbrains.github.io/kotlin-spec/
にそれに関する事のってねぇな？
DartだってECMAでしっかりした仕様書になってるのに、
仕様書がいまだにこんなレベルなのにAndroidのFirst Class Languageにするなんて
Google何考えてんだか・・
後、
https://ideone.com/RIMEHi
で、
val t = Test()
t.update()
にすると、propertyが変更されないっぽいんですけど、なんででしょうか？？
Android環境でコルーチンを使ってます
よろしくお願いします。
https://ideone.com/RIMEHi
で、
val t = Test()
t.update()
にすると、propertyが変更されないっぽいんですけど、なんででしょうか？？
Android環境でコルーチンを使ってます
よろしくお願いします。
ダメだこの言語…はやく何とかしないと…
え、Androidやろうと思って今ならKotlinかなって思って調べてたのに。
>>787
Androidやコルーチンであることは直接の関係が無く
インラインでないラムダとprivate setの組み合わせが影響しているようだ
https://ideone.com/aLit2X
↑これの「4」が出力されるケースと同じでsetの処理を通らずに
バッキングフィールドに直に代入されてると思う
バグか仕様か断言はしないけど、多分コンパイラのバグじゃないかな
Androidやコルーチンであることは直接の関係が無く
インラインでないラムダとprivate setの組み合わせが影響しているようだ
https://ideone.com/aLit2X
↑これの「4」が出力されるケースと同じでsetの処理を通らずに
バッキングフィールドに直に代入されてると思う
バグか仕様か断言はしないけど、多分コンパイラのバグじゃないかな
この前のもだけど誰かバグとして報告してあげて…
そうだよね。俺もちょっと前というか昨日もそうだけど、>>787のまた変な動きに出くわして
さすがにうんざりしてIssue Trackerのぞいたけど、前のも報告されてないっぽいよねww
つか、前のやつは単なるコンパイラのバグですまされない仕様修正とか入りそうな予感してるんだけど。
まぁ、現状の仕様ってのがなんだかよくわからんけど。
さすがにうんざりしてIssue Trackerのぞいたけど、前のも報告されてないっぽいよねww
つか、前のやつは単なるコンパイラのバグですまされない仕様修正とか入りそうな予感してるんだけど。
まぁ、現状の仕様ってのがなんだかよくわからんけど。
じゃあiOS開発に引きこもってろ
コンパイラのバグはバグとして直すのが当然だけど
この前のバッキングフィールドの初期化回避や
setter内のインラインでないラムダからバッキングフィールドにアクセスするのを
普通のアプリ開発として書いているのなら止めた方が良いと思う
個人的な感覚では動作以前に「コンパイルが通るべきでは無いコード」だと思うので
この前のバッキングフィールドの初期化回避や
setter内のインラインでないラムダからバッキングフィールドにアクセスするのを
普通のアプリ開発として書いているのなら止めた方が良いと思う
個人的な感覚では動作以前に「コンパイルが通るべきでは無いコード」だと思うので
仕様がないとバグかそうでないか判断できないが仕様はどこにあるんだ？
kotlinで3000行くらいすでに書いちゃったけど、とりあえず、private setをpublic setに直して回避・・
しばらくflutterで遊んでくるか
しばらくflutterで遊んでくるか
しようがないなあ
醤油が無いなぁ
死なないかなぁ
これからプログラミング初心者がkotlinを触るようになったらそこらへんも色々見つかるだろうね
今はまだほぼ他の言語で経験のある人しか触ってないでしょ
今はまだほぼ他の言語で経験のある人しか触ってないでしょ
こんな事いうと荒れるけど、逆だと思う
他の言語っていうか、java本業の人しか触ってないでしょ
Androidの入門書もまだほぼjavaばっかだし
Androidの入門書もまだほぼjavaばっかだし
コマンドラインから何も引数付けずに kotlinc 実行するとRPELで動くけどこの時に :help で出てくる :dump bytecode ってなんなの？
名前からしてバイトコードをダンプするであろうことはわかるけど、いつやっても何も出ないんだよね。
名前からしてバイトコードをダンプするであろうことはわかるけど、いつやっても何も出ないんだよね。
タイプミスった。rpelじゃねえ。replだ。
C#のnameof演算子だと、コンパイル時に評価されますけど。
kotlinのプロパテイ参照は結構オーバーヘッド高いですかね？？
when (propertyName) {
::property1.name ->
::property2.name ->
}
結構頻繁に評価されるコードなんですよね
kotlinのプロパテイ参照は結構オーバーヘッド高いですかね？？
when (propertyName) {
::property1.name ->
::property2.name ->
}
結構頻繁に評価されるコードなんですよね
今は定数でやってんですけど、まだ書き換えるべきが保留してるんです。
when (propertyName) {
"property1" ->
"property2" ->
}
リフレクション絡みのオブジェクトも普通にGC対象？で、その都度生成されたり破棄されたりすると予想しますが。
もちろんアプリ全体のボトルネックになるぐらい影響はないですけど、うーん。踏ん切りがつかん。
when (propertyName) {
"property1" ->
"property2" ->
}
リフレクション絡みのオブジェクトも普通にGC対象？で、その都度生成されたり破棄されたりすると予想しますが。
もちろんアプリ全体のボトルネックになるぐらい影響はないですけど、うーん。踏ん切りがつかん。
Enumじゃだめ？
>>810
ありがとうございます。そうですね。プロパティ増やすたびにEnumの定数も定義する必要がありますが、
パフォーマンス的にはいいですよね。
で、今ちょっと見たことなかったんですけど、Javaのバイトコード見てみたんですけど最適化されてるのか？？
メソッド呼び出しされてるのかと思ったら、定数値に置き換えられてました。
最適化のせいなら将来のコンパイラでどうなるかわかりませんけど、とりあえず、普通にプロパティ参照使って
置き換えてます。
ありがとうございました。
ありがとうございます。そうですね。プロパティ増やすたびにEnumの定数も定義する必要がありますが、
パフォーマンス的にはいいですよね。
で、今ちょっと見たことなかったんですけど、Javaのバイトコード見てみたんですけど最適化されてるのか？？
メソッド呼び出しされてるのかと思ったら、定数値に置き換えられてました。
最適化のせいなら将来のコンパイラでどうなるかわかりませんけど、とりあえず、普通にプロパティ参照使って
置き換えてます。
ありがとうございました。
でもそれ結局今日も同じメニューになるよな
たまにはやよい軒行きたいわ、遠いけど
たまにはやよい軒行きたいわ、遠いけど
すまん誤爆した
Xamarinのライセンス買ってくるわ
Xamarinのライセンス買ってくるわ
俺は大戸屋が多いかな
俺はとんでんかな
やよい軒の鳥カツ定食なくなったらしいな
あれしか食わなかったのに
あれしか食わなかったのに
それは残念
waitとかマルチスレッド機能ぐらい用意しとけよー
結局java.lang.Objectから離れれられんじゃないか
結局java.lang.Objectから離れれられんじゃないか
逆に言えばJavaの機能で出来ることをわざわざKotlinで独自に作り直す必要ってあるかね
クロスプラットフォーム押していくなら、Javaからある程度離れて開発できないとな。
Kotlin=JVMなら別にいいけど。
Kotlin=JVMなら別にいいけど。
flutterがKotlinでできるようになったら流行りそうなのになー
それが一番だけど、そうなるにはそうなるにはJetBrainsの対応待ってると時間かかりそうだから、
Google買収しないと。IDE全体抱えてもあれだからkotlin部門だけでも
Google買収しないと。IDE全体抱えてもあれだからkotlin部門だけでも
ゆくゆくはそうなっていくかもしれないけど、まずはJava完全互換を徹底して開発者を集めないとKotlin自体終わっちゃうし
JVMがLLVM上で開発されるようになれば...
日本のことりん本の電書、固定レイアウトなのか・・・
ことりん本に限らず図表の多い専門書は基本固定レイアウトが多い
超初心者で申し訳ありません。
Kotlinスタートブックを購入しました。
REPLを多用してるのでAndroid Studio3.01のREPLで進めたいのですが、
単純に、Kotlin REPLパネル内に、書籍のコード～ じゃ無いようで、今一つ、Android StudioのREPLの使い方が分かりません。
Android Studio3.01のREPLで、「Kotlinスタートブック」をスターと部分だけでも紹介してる情報なありますでしょうか？
Kotlinスタートブックを購入しました。
REPLを多用してるのでAndroid Studio3.01のREPLで進めたいのですが、
単純に、Kotlin REPLパネル内に、書籍のコード～ じゃ無いようで、今一つ、Android StudioのREPLの使い方が分かりません。
Android Studio3.01のREPLで、「Kotlinスタートブック」をスターと部分だけでも紹介してる情報なありますでしょうか？
あれこれして
書籍 P28の最初の一発目
class Rational(val numerator: Int, val denominator: Int)
val half = Rational(1,2)
half.denominator
と、打ち込んで 実行させたら、２って出来ました～
Android Studio3.01のREPLを使って、読みすすめそうです。
書籍 P28の最初の一発目
class Rational(val numerator: Int, val denominator: Int)
val half = Rational(1,2)
half.denominator
と、打ち込んで 実行させたら、２って出来ました～
Android Studio3.01のREPLを使って、読みすすめそうです。
解決したみたいだからいいけど、
技術書を写経するときはREPLよりもコードをファイルとして残しておいた方がいいと思うよ
読み進めた後にちょっと前に見たところを戻って書き換えたりとかしたくなることが多いと思う
技術書を写経するときはREPLよりもコードをファイルとして残しておいた方がいいと思うよ
読み進めた後にちょっと前に見たところを戻って書き換えたりとかしたくなることが多いと思う
フィードバックが早い方がいいからREPLでいい
肴は炙った烏賊でいい
女は無口な人がいい
ちょこちょこバージョンアップしてるみたいだけど、リリースノートってあるのかな？
Swiftのバージョンアップは破壊的変更が多くてダルいらしいけどKotlinはどうなの？
いい感じ
>>835
Android studio使ってるならファイルをデバッグ実行してEvaluate Expressionするのが1番フィードバックが早くて使い勝手も良い
Android studio使ってるならファイルをデバッグ実行してEvaluate Expressionするのが1番フィードバックが早くて使い勝手も良い
>>843
ごくごく初期はなんか色々あったらしいけど、最近は既存のコードが動かなくなるような変更は記憶にないな。
そこらへんはJavaのカルチャーかも
ごくごく初期はなんか色々あったらしいけど、最近は既存のコードが動かなくなるような変更は記憶にないな。
そこらへんはJavaのカルチャーかも
ライブラリが充実してて扱いが楽だからな
あ、すまん。ちゃんと読んでなかった。
入門の文脈か
入門の文脈か
ぶっちゃけ、PythonとKotlin覚えときゃ十分だよな
ソース見られてもいいようなちょっとした内部処理はPythonでやって、それ以外はKotlinでやればいいし
ソース見られてもいいようなちょっとした内部処理はPythonでやって、それ以外はKotlinでやればいいし
REPLの使い方の説明ないんだよねあの本
ぶっちゃけ最初からいきなりファイル書いたほうがいいと思うわ
ぶっちゃけ最初からいきなりファイル書いたほうがいいと思うわ
REPL の :dump bytecode が未だにわからん。
分かるやつは居ないのか？
分かるやつは居ないのか？
githubで検索してmasterブランチのソース見たけど :dump bytecodeの対象は
ReplFromTerminal 経由で ReplInterpreterが直に持ってるReplClassLoaderで
ReplClassLoaderはaddClassされたものをdumpするみたい
それで addClass探したら HistoryActionsForNoRepeat で
ReplClassLoaderを新たに生成してaddClassしてるのしか見当たらなかった
読み間違いでなければ、addと列挙を異なるReplClassLoaderインスタンスでやってるので
dump bytecodeは常に何も出ないのでは
ReplFromTerminal 経由で ReplInterpreterが直に持ってるReplClassLoaderで
ReplClassLoaderはaddClassされたものをdumpするみたい
それで addClass探したら HistoryActionsForNoRepeat で
ReplClassLoaderを新たに生成してaddClassしてるのしか見当たらなかった
読み間違いでなければ、addと列挙を異なるReplClassLoaderインスタンスでやってるので
dump bytecodeは常に何も出ないのでは
HistoryActionsForNoRepeatで作られるReplClassLoaderは
topClassLoaderと合わせて3重にネストしてるように見える
ReplClassLoader (HistoryActionsForNoRepeatのメソッド内のclassLoader)
→親 URLClassLoader
→親 ReplClassLoader (状態によってはGenericReplEvaluatorStateのtopClassLoader)
→親 URLClassLoader
→親 ReplClassLoader (ReplInterpreterのclassLoader)
→親 URLClassLoader
makeReplClassLoaderは引数のbaseClassloaderがReplInterpreterだったら
newせず引数をキャストして返した方がいいような気が
topClassLoaderと合わせて3重にネストしてるように見える
ReplClassLoader (HistoryActionsForNoRepeatのメソッド内のclassLoader)
→親 URLClassLoader
→親 ReplClassLoader (状態によってはGenericReplEvaluatorStateのtopClassLoader)
→親 URLClassLoader
→親 ReplClassLoader (ReplInterpreterのclassLoader)
→親 URLClassLoader
makeReplClassLoaderは引数のbaseClassloaderがReplInterpreterだったら
newせず引数をキャストして返した方がいいような気が
× ReplInterpreterだったら
○ ReplClassLoaderだったら
○ ReplClassLoaderだったら
>>856
わからないことがあったらコードを読む習慣がある奴と乞食するだけのお前
どんどん差は開いていくんだろうなぁ
わからないことがあったらコードを読む習慣がある奴と乞食するだけのお前
どんどん差は開いていくんだろうなぁ
ん？
お！
まー、わからないことがあればコード読むのが一番だけど、読まなくても質問の仕方ってもんがあるよな
どなたかお分かりになる方はいらっしゃいませんか？
だよな、普通は
だよな、普通は
お客様の中にお医者様はいらっしゃいませんか？
おう、帰っていいぞ
寒いな
春なのに
春なのに
この一言を添えるべきだったな。
「わからない人は書かないでください。」
「わからない人は書かないでください。」
3E 00
18 FC
GOTO CA FE
55 4E 4B 4F
前々から思ってたけどkotlinスレって加齢臭すごいよな
あいむふぉーてぃーふぁいぶにやーずおーるど
にやーず
マグナムドライをマグマグドライと呼ぶほど落ちぶれてはいない
まぐまぐドライだろ普通。
Graalって今年のJava11に間に合うのか？
Kotlin/Native（LLVM）なんかよりずっと期待できそうだが。
Kotlin/Native（LLVM）なんかよりずっと期待できそうだが。
GraalとKotlin/Nativeって用途もコンセプトも被ってないと思うんだけど
LLVMの使い方も逆方向だし
LLVMの使い方も逆方向だし
Graalがどうとかいう以前に、JVMがないプラットフォームがあるのを何とかして欲しい。
ライブラリも含めてコードをそのまま持ち込んでも動くならともかく、Graalで多言語をサポートしても、
各言語の基本仕様だけでは大したことは出来ない。
ライブラリも含めてコードをそのまま持ち込んでも動くならともかく、Graalで多言語をサポートしても、
各言語の基本仕様だけでは大したことは出来ない。
run sometime somewhereだから仕方ない
Graal
世界大百科事典内のGraalの言及
【聖杯伝説】より
…12世紀末ヨーロッパで顕在化したキリスト教の色濃い伝説だが，起源には諸説あり，
ケルト説話を源とする考えが有力。聖杯Graal(英語はGrail)を扱った最初の作品は
フランスの詩人クレティアン･ド･トロアの《ペルスバルまたは聖杯物語》(1185ころ)。
主人公が漁夫王の城で目にしたふしぎな行列，血の滴る槍と光り輝く聖杯について，
心に抱いた質問を口に出さなかった失敗がすべての発端であった。…
https://kotobank.jp/word/Graal-1233958
世界大百科事典内のGraalの言及
【聖杯伝説】より
…12世紀末ヨーロッパで顕在化したキリスト教の色濃い伝説だが，起源には諸説あり，
ケルト説話を源とする考えが有力。聖杯Graal(英語はGrail)を扱った最初の作品は
フランスの詩人クレティアン･ド･トロアの《ペルスバルまたは聖杯物語》(1185ころ)。
主人公が漁夫王の城で目にしたふしぎな行列，血の滴る槍と光り輝く聖杯について，
心に抱いた質問を口に出さなかった失敗がすべての発端であった。…
https://kotobank.jp/word/Graal-1233958
JavaのコードをKotlinにIntteliJさん使って変換すると
fun hogehoge(value: String): Int? {
var value = value
みたいなコードでName shadowedってワーニングがでる
仕方ないのでvar_value = valueみたいに名前変えてんだけど、どうするのがベストかな？これ以外に良い方法あったら教えて
fun hogehoge(value: String): Int? {
var value = value
みたいなコードでName shadowedってワーニングがでる
仕方ないのでvar_value = valueみたいに名前変えてんだけど、どうするのがベストかな？これ以外に良い方法あったら教えて
ウォーニング
ぅおー
>>887
Analyze>Inspect Code
結果窓で気に入らないインスペクションを選択しスパナアイコンから設定画面でdisableする
Analyze>Inspect Code
結果窓で気に入らないインスペクションを選択しスパナアイコンから設定画面でdisableする
Inspect Codeをどこをどういじったら変わるのか分からない
プロファイルってやつ？
名前の通りインテリすぎて使いこなせてない・・・orz
プロファイルってやつ？
名前の通りインテリすぎて使いこなせてない・・・orz
def initialize (number)
@number = number
end
Ruby のクラス内の、インスタンスメソッドの引数を、インスタンス変数に代入するなど、
@ の有無で、判別できるなら良いけど、
関数の引数と、関数内の変数は、共にローカルスコープで、
完全に、変数名もスコープも一致しているから、明らかな間違い
@number = number
end
Ruby のクラス内の、インスタンスメソッドの引数を、インスタンス変数に代入するなど、
@ の有無で、判別できるなら良いけど、
関数の引数と、関数内の変数は、共にローカルスコープで、
完全に、変数名もスコープも一致しているから、明らかな間違い
>>887
Inspectionを切れば出なくなるしなんなら無視してもいいけど、そのコードは明らかに書くべきでないからコードを直した方が良い。
引数が変数の名前を変えるべき。
Inspectionを切れば出なくなるしなんなら無視してもいいけど、そのコードは明らかに書くべきでないからコードを直した方が良い。
引数が変数の名前を変えるべき。
受け取った値に何かしらの加工を加えて返却する関数だと推測するけど
それなら引数の方をrawValueにするとか、変数の方をnewValueにするとか
なんでもいいけどとりあえずそのコードは俺がコードレビューするなら絶対指摘する
それなら引数の方をrawValueにするとか、変数の方をnewValueにするとか
なんでもいいけどとりあえずそのコードは俺がコードレビューするなら絶対指摘する
Javaで
a instanceof CharSequence[]
してた部分はKotlinではどう置き換えたらいいでしょうか？
a is Array<CharSequence>
だとcannot check for instance of erased typeでエラーがでて型チェックができません。
a instanceof CharSequence[]
してた部分はKotlinではどう置き換えたらいいでしょうか？
a is Array<CharSequence>
だとcannot check for instance of erased typeでエラーがでて型チェックができません。
うちのKotlinはエラーにならないな
https://ideone.com/IAkBb8
あれ、マジですか。Android Studioの方で駄目です。
バージョンって
ext.kotlin_version = '1.2.21'
これかな
あれ、マジですか。Android Studioの方で駄目です。
バージョンって
ext.kotlin_version = '1.2.21'
これかな
ああ、aが実際にArray<CharSequence>のときはエラーにならないぽい
Array<*>にするしかないのかなあ
Array<*>にするしかないのかなあ
if(a is Array<*>) {
b = a.filterIsInstance<CharSequence>().toTypedArray()
}
とかは？
b = a.filterIsInstance<CharSequence>().toTypedArray()
}
とかは？
途中で送っちゃった
JavaのコードからAnyでくる何かの配列を扱いたいときに確かこんな感じで書いた記憶が
JavaのコードからAnyでくる何かの配列を扱いたいときに確かこんな感じで書いた記憶が
勉強しようと思いリファレンス読みつつ Koans をやり始めた
最初は var, val や if, for とかかなと思ってたから面食らった
最初は var, val や if, for とかかなと思ってたから面食らった
小手ぇッ！
|Д｀) ﾀﾞﾚﾓｲﾅｲ･･
|∀｀) ことりんするならｲﾏﾉｳﾁ!!
Java訴訟で神託に負けたから、次バージョンからkotlinかな
やっぱりこのスレおっさんしかいないな
中身？？
Googleが一兆円払ったら今までと同じようにAndroid使っていけるんですかね
Androidがなくなるみたいな話じゃないんですかね
Androidがなくなるみたいな話じゃないんですかね
長期的にはAndroidはJavaから離れてSwift化していくと思う
Kotlinはそれまでの繋ぎだろう
構文似てるし
Kotlinはそれまでの繋ぎだろう
構文似てるし
問題になっているのはAPI仕様なんで、kotlinに変えただけじゃ解決しないよ。
googleは企業間摩擦で割と子供っぽい対応をするところがあるので、神託を敵対買収とか糞味噌展開を期待。
googleは企業間摩擦で割と子供っぽい対応をするところがあるので、神託を敵対買収とか糞味噌展開を期待。
ねーよ
また控訴してひっくり返らないか？
SwiftがKotlin化しろよ
しかしGoogleがフェアユースとか言い出さなければよかっただけなんじゃないかという感じがする。
つうかAndroidもOpenJDKに移行するんだからもうその訴訟自体どうでも良くなるんじゃねーの
swiftは破壊的変更が多すぎてkotlinが良い
俺も今のところkotlin。かといってswiftほとんど知らないわけだが。Apple関係に手を出さない限り必要性がほとんどないよなあれ。
まあ今後変わるかも知れないが。
まあ今後変わるかも知れないが。
フェアユースの方はまだ上告できるけど
ひっくり返る望みはほぼ無いようだから諦めて払うか別の弾持ち出してさらに粘るかだろうね
払うにしても時間たってるから賠償請求額上乗せしてくるんだろうけど
損害賠償だけで使用差し止めは要求してないからAndroidからJavaAPIが消えるという事は無い
はず
ひっくり返る望みはほぼ無いようだから諦めて払うか別の弾持ち出してさらに粘るかだろうね
払うにしても時間たってるから賠償請求額上乗せしてくるんだろうけど
損害賠償だけで使用差し止めは要求してないからAndroidからJavaAPIが消えるという事は無い
はず
その前にfuchsiaへの移行を狙ってるはず
kotlinってAndroid関係以外でも需要あんの？
Swiftはよくできてると思うが、毎年変更があるのがいけてないな
まぁー、Javaもついこないだ9出たと思ったら、もう10が出てたりするけど
まぁー、Javaもついこないだ9出たと思ったら、もう10が出てたりするけど
javaが全部Kotlinに置き換わる
今プログラミング言語で一番使われてるのがjava
つまりKotlin最強になるということだ
今プログラミング言語で一番使われてるのがjava
つまりKotlin最強になるということだ
Nativeがあるといいけどライブラリどうなるのって問題があるな
>>927
JAVAでできることならなんでもできる。サーバーサイドのことでも。
Kotlin/Nativeが1.0になれば、応用範囲はさらに広がる。こっちはいつになるかわかんないけど。
JAVAでできることならなんでもできる。サーバーサイドのことでも。
Kotlin/Nativeが1.0になれば、応用範囲はさらに広がる。こっちはいつになるかわかんないけど。
javaでできることしかできない
CのDLL呼び出しというかWinAPIはJavaより楽にできるの？
つまり、動かすにはJavaランタイムのインストールが必須ってことですかね
デフォルトでJREが入ってないMacのアプリを作るのはきついかな
ちなみに、SwiftでもWebアプリのサーバサイド書けるし、コマンドラインで手動コンパイルなしで実行するスクリプト的な使い方もできます。REPLもついてくるし
デフォルトでJREが入ってないMacのアプリを作るのはきついかな
ちなみに、SwiftでもWebアプリのサーバサイド書けるし、コマンドラインで手動コンパイルなしで実行するスクリプト的な使い方もできます。REPLもついてくるし
>>931
もともと、Javaを拡張するのが大変だから、突破口として、Kotlinという新しい言語を作ったといういきさつなので、Javaでできないこともできる。
最近だとコルーチンとか。
もともと、Javaを拡張するのが大変だから、突破口として、Kotlinという新しい言語を作ったといういきさつなので、Javaでできないこともできる。
最近だとコルーチンとか。
Swift程の糞はない
サーバーサイドをSwiftで作るメリットが何一つ思いつかない
そういやKotlinはOpenJDKのJREがあれば動くからAndroid以外ではライセンス気にする必要がないね。
Swiftプログラマがスキルをそのまま活かせるというメリットがありますよ
>>911
理解が違ってたらすまんけど記述言語がKotlinだとしても中身はJavaにコンバートしてAndroid上で動いてるんじゃないの？という意味。
理解が違ってたらすまんけど記述言語がKotlinだとしても中身はJavaにコンバートしてAndroid上で動いてるんじゃないの？という意味。
>>939
コンバートはしてないのでは？直接JVM用のバイトコード出してると思うが。
まあ、それができるならコンバートもできる筈だとは思うけどね。
コンバートはしてないのでは？直接JVM用のバイトコード出してると思うが。
まあ、それができるならコンバートもできる筈だとは思うけどね。
>>941
ググってみた。ORACLEの特許はJava APIに対してなんだな。
ORACLEの特許はJava全般に渡ると思ってたのでバイトコードに変換しても（俺はこれをコンバートと言ってた。理解出来てなくてすまない）JMVで動いてる事自体が特許にひっかかるんじゃないかと思ってた。
Android OSのソースの特許で揉めてる部分をKotlinに置き換えれば大丈夫って事になるのかな。
ググってみた。ORACLEの特許はJava APIに対してなんだな。
ORACLEの特許はJava全般に渡ると思ってたのでバイトコードに変換しても（俺はこれをコンバートと言ってた。理解出来てなくてすまない）JMVで動いてる事自体が特許にひっかかるんじゃないかと思ってた。
Android OSのソースの特許で揉めてる部分をKotlinに置き換えれば大丈夫って事になるのかな。
apple傘下のものをメインにするのはやっぱちょっと怖い
G様なら飽きたら放置だからそこは安心
G様なら飽きたら放置だからそこは安心
>942
androidで使ってたdalvikはレジスタマシンじゃん。
素のjvmならスタックマシンだからそこで特許は無理じゃね？
あとAPIだってそれだけじゃ特許とれんだろ。オラクルも特許侵害は言ってなかったような。
androidで使ってたdalvikはレジスタマシンじゃん。
素のjvmならスタックマシンだからそこで特許は無理じゃね？
あとAPIだってそれだけじゃ特許とれんだろ。オラクルも特許侵害は言ってなかったような。
プログラミング言語なんて適材適所だからな
少なくとも現時点ではサーバーサイドSwiftなんて選択肢としては悪手の中の悪手だわ
言語機能云々じゃなくて、エコシステム全体で見た時にあえてSwiftを選ぶ理由が本当に何もない
少なくとも現時点ではサーバーサイドSwiftなんて選択肢としては悪手の中の悪手だわ
言語機能云々じゃなくて、エコシステム全体で見た時にあえてSwiftを選ぶ理由が本当に何もない
Xamarin程の糞はない
そんな狂信者召喚呪文を唱えなくてもw
>>936
かつてそれと全く同じ理屈でなんでもかんでもJavascriptで作ろうといわれた時代があってだな
かつてそれと全く同じ理屈でなんでもかんでもJavascriptで作ろうといわれた時代があってだな
node,jsはバリバリの現役じゃん
かつてじゃなくて今もNode.jsはそこそこ流行ってるじゃん
Electronで作ってるVSCodeとかかなり使いやすいぞ
まー自分は使う気になれんが
Electronで作ってるVSCodeとかかなり使いやすいぞ
まー自分は使う気になれんが
googleはkotlinやってるのにflutterでdartとか、一つに絞らんのかね？
絞ってるだろ
なんか勘違いしてるようだが、Google自身はKotlinもDartも一切使ってないぞ
なんか勘違いしてるようだが、Google自身はKotlinもDartも一切使ってないぞ
結局、ちんこが勃つか勃たないかが重要なんだ
人を見た目で判断してはいけないと理屈で考えたとしても
ちんこが勃つか勃たないかまでは理性でコントロールはできない
だから男の方から女を選ぶ必要がある
女の方からいくら好きだと言って男に言い寄ってもちんこが勃たなければそこで終わりなのだ
男の方から女の方に言い寄る分には問題ない。ちんこが勃つということを表明しているのと同じだからだ
従って、肉食系女子、草食系男子というのはありえないということ
人を見た目で判断してはいけないと理屈で考えたとしても
ちんこが勃つか勃たないかまでは理性でコントロールはできない
だから男の方から女を選ぶ必要がある
女の方からいくら好きだと言って男に言い寄ってもちんこが勃たなければそこで終わりなのだ
男の方から女の方に言い寄る分には問題ない。ちんこが勃つということを表明しているのと同じだからだ
従って、肉食系女子、草食系男子というのはありえないということ
>>922
アメリカだと巨額な賠償命令が出るときは青天井のことはあるけど、
賠償請求額ってふっかけることが多いから、賠償額の審理が終わったら
「8年も引っ張ってこれだけかよ!」みたいな額だったというオチもありえなくはない。
アメリカだと巨額な賠償命令が出るときは青天井のことはあるけど、
賠償請求額ってふっかけることが多いから、賠償額の審理が終わったら
「8年も引っ張ってこれだけかよ!」みたいな額だったというオチもありえなくはない。
しかしAPIが著作権の問題で使ってはいけないとなると、その他のOSやライブラリもそうなりかねんわけで、
コンピュータ業界全体が大混乱に陥るのではないか?
以前 Linux でも似たような点が問われたことがあったように思うが、Linux に UNIX と同じシステムコールを
作った場合に関数名が同じとか関連する定数の定義が同じとか、呼び出し方や機能が同じになるわけで、
その部分に著作権があると言われて使用不能になったら互換OSや互換ライブラリは全滅になる。
同じ機能があっても違う呼び出し方しなければいけなくなってしまうからな。同じファイルオープンなのに
open() が使えないなんてなったらかなりアホらしいしもはやそんなもん障害でしかなかろう。
(変換すればいいのでその内なんとかなるだろうが、とても面倒だ)。
コンピュータ業界全体が大混乱に陥るのではないか?
以前 Linux でも似たような点が問われたことがあったように思うが、Linux に UNIX と同じシステムコールを
作った場合に関数名が同じとか関連する定数の定義が同じとか、呼び出し方や機能が同じになるわけで、
その部分に著作権があると言われて使用不能になったら互換OSや互換ライブラリは全滅になる。
同じ機能があっても違う呼び出し方しなければいけなくなってしまうからな。同じファイルオープンなのに
open() が使えないなんてなったらかなりアホらしいしもはやそんなもん障害でしかなかろう。
(変換すればいいのでその内なんとかなるだろうが、とても面倒だ)。
お前らの作る糞アプリには関係ねえよ
>>958
・Wineは使えなくなってしまい、もはや、Windowsの互換OSは未来永劫作れない。
・mingw32 の windows.h ヘッダも著作権的にダメなのかい。
・こうなったのは、アメリカの法制度が悪いから。
世界中のみんなが、アメリカの法律は無視しよう。
・Wineは使えなくなってしまい、もはや、Windowsの互換OSは未来永劫作れない。
・mingw32 の windows.h ヘッダも著作権的にダメなのかい。
・こうなったのは、アメリカの法制度が悪いから。
世界中のみんなが、アメリカの法律は無視しよう。
いやヘッダの著作権は普通にあるぞ
著作権の利用許諾に反するかどうかの問題
著作権の利用許諾に反するかどうかの問題
お前らみたいな糞に人権はねえよ
∧＿∧ ／￣￣￣￣￣
（ ´∀｀）＜ オマエモナー
（ ） ＼＿＿＿＿＿
│ │ │
（＿_）___）
（ ´∀｀）＜ オマエモナー
（ ） ＼＿＿＿＿＿
│ │ │
（＿_）___）
>>958
linuxの場合は参考にしてるのがposixだからまたちょっと事情が異なるんじゃない？
著作権問題でゴタゴタしてたのはBSDですな。
あれはBSD失速の要因の一つだったと思う。
linuxの場合は参考にしてるのがposixだからまたちょっと事情が異なるんじゃない？
著作権問題でゴタゴタしてたのはBSDですな。
あれはBSD失速の要因の一つだったと思う。
以前の会社にBSDを好んで使ってる人が結構いたけど、まだ使ってるんだろうか
そんな心配してる私はMacユーザーw
そんな心配してる私はMacユーザーw
>>961
「コメント」などには著作権はあるけれど、関数のプロトタイプ宣言や構造体定義にまで
著作権を認めてしまうと、互換ライブラリ、互換言語処理系などを作ることが全くできなく
なってしまい、人々は困る。
「コメント」などには著作権はあるけれど、関数のプロトタイプ宣言や構造体定義にまで
著作権を認めてしまうと、互換ライブラリ、互換言語処理系などを作ることが全くできなく
なってしまい、人々は困る。
>>966
お前は関数のシグネチャを見ただけで互換実装を書けるエスパーなのか？
APIリファレンスや元のソースコードを読んで実装したら、やってることは実質的に盗作だよ
お前は関数のシグネチャを見ただけで互換実装を書けるエスパーなのか？
APIリファレンスや元のソースコードを読んで実装したら、やってることは実質的に盗作だよ
MacというかNeXTはどちらかというとBSD系だろ
>>967
料理本に書いてあるやり方を真似て、別の本を出しても、著作権侵害にはならない判例
がアメリカでは基本になっている。
だから、リファレンスを理解して同じ機能のAPIを作っても著作権侵害にはならないと言うのが
原則だとされる。
料理本に書いてあるやり方を真似て、別の本を出しても、著作権侵害にはならない判例
がアメリカでは基本になっている。
だから、リファレンスを理解して同じ機能のAPIを作っても著作権侵害にはならないと言うのが
原則だとされる。
googleも似たようなAPIを作って差し替えればいいんじゃねえの
>>970
だからflutterで仕切り直しをしたいんかな。
ついでにosもlinux辞めて全部自分仕切りにしようってことかね
だからflutterで仕切り直しをしたいんかな。
ついでにosもlinux辞めて全部自分仕切りにしようってことかね
だからJavaとかいう臭い言語なんか最初から使ってなきゃよかったんだよ
オラクルとかいう臭い企業が牛耳ってる言語なんか使わないでも
もっと良い言語作れる能力あるのに
使用者が多いからと開発者に媚びた結果がこれだよ
オラクルとかいう臭い企業が牛耳ってる言語なんか使わないでも
もっと良い言語作れる能力あるのに
使用者が多いからと開発者に媚びた結果がこれだよ
Appleみたいにちゃんと買い取った会社と言語でやるべきだったな
2003年時点のAndroid社が今の状況を予想できるわけがない
Kotlinってのは内部でJavaに変換してるの？
はぁ？
バイトコード吐いてんだろが
バイトコード吐いてんだろが
javaのソースコードという意味なら、してない
>>980
駄目だよ。
問題になっているのはjava APIの著作権なので、それがclassライブラリを指しているのかvm仕様を指してるのかわからんが、いずれにしてもkotlinでも状況は一緒。
ただandroidは神託が自らgpl化したopen jdkに移行したから、今後はjavaを使い続けても問題ない、はず
駄目だよ。
問題になっているのはjava APIの著作権なので、それがclassライブラリを指しているのかvm仕様を指してるのかわからんが、いずれにしてもkotlinでも状況は一緒。
ただandroidは神託が自らgpl化したopen jdkに移行したから、今後はjavaを使い続けても問題ない、はず
>>973
元は臭く無かったよ
ただSunが弱った結果、Oracleに訴訟用の道具として買収されてそうなった
元は臭く無かったよ
ただSunが弱った結果、Oracleに訴訟用の道具として買収されてそうなった
>>981
やっぱり駄目なのか
Kotlinに完全移行する覚悟しようかと思ってたけど
OpenJDKで生きながらえるなら考え直そうかな
やっぱり駄目なのか
Kotlinに完全移行する覚悟しようかと思ってたけど
OpenJDKで生きながらえるなら考え直そうかな
個人で作るならコトリンのが作りやすいやろ
仕事だとなかなか採用できんね
仕事だとなかなか採用できんね
次スレってあるの?
>>982
サンもJAVAの言語自体で儲からんかゴニョゴニョしていたせいで
（ISOなどに渡してしまうなどできただろうに拒んだ）オラクルが
滅茶苦茶やれるようにしてしまったという面もある。
サンもJAVAの言語自体で儲からんかゴニョゴニョしていたせいで
（ISOなどに渡してしまうなどできただろうに拒んだ）オラクルが
滅茶苦茶やれるようにしてしまったという面もある。
>>985
ある。かなり前に俺が間違えて立てた。w
Kotlin 3
http://2chb.net/r/tech/1521401186/
ある。かなり前に俺が間違えて立てた。w
Kotlin 3
http://2chb.net/r/tech/1521401186/
オラクルなんなん
てかフェアユース不適合なの意味わからん
てかフェアユース不適合なの意味わからん
なんらかの理由でgoogleの足を引っ張りたかっただけだろ
下手したらITの世界全体に致命的なダメージを与えかねないクソ前例を作りやがった
下手したらITの世界全体に致命的なダメージを与えかねないクソ前例を作りやがった
オラクルが足を引っ張らなかったことなんてほぼ無い
>>993
お前何にも理解してないんだな。
J++は互換実装を作ったことが問題になったんじゃねえよ。
お前何にも理解してないんだな。
J++は互換実装を作ったことが問題になったんじゃねえよ。
いきなり、お前呼ばわりって頭可笑しいと思うの。
先ずはお礼でしょう？
先ずはお礼でしょう？
お前呼ばわりは酷いな
せめてお主だろ
せめてお主だろ
せめてさんをつけろ
ねえお前さん
ねえお前さん
1000ならXamarinのライセンスを1000個買う
mmp2
lud20190627103912caこのスレへの固定リンク： http://5chb.net/r/tech/1509462463/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
ブックマークへ |
|---|
全掲示板一覧 この掲示板へ 人気スレ | Youtube 動画 >50 >100 >200 >300 >500 >1000枚 新着画像
↓「Kotlin 2 YouTube動画>1本 ->画像>7枚 」を見た人も見ています：
・次世代言語12 Go Rust Swift Kotlin TypeScript
・Kotlin 5
・Kotlin 6
・Kotlin 3
・Kotlin 4
・Dart これ以上変な言語を増やすんじゃねえ！ Kotlin
・次世代言語13 Go Rust Swift Kotlin TypeScript
・次世代言語15 Go Rust Swift Kotlin TypeScript
・次世代言語15 Go Rust Bosque Kotlin TypeScript
・次世代言語Part8[Haskell Rust Kotlin TypeScript]
・次世代言語9[Haskell Rust Kotlin TypeScript Dart]
・次世代言語14 Go Rust Swift Kotlin TypeScript
・次世代言語17 Go Rust Kotlin TypeScript Julia
・次世代言語Part7[Go Rust Swift Kotlin TypeScript]
・次世代言語議論スレ[Rust Kotlin Haskell]第6世代
・次世代言語18 Go Rust Elixir Kotlin TypeScript
・次世代言語22 Go Nim Rust Swift Kotlin TypeScript
・KoRn Limp Bizkit Slipknot DISTURBED LINKIN PARK
・【IT】Kotlin 1.2正式版リリース。KotlinはJavaとJavaScriptのマルチプラットフォーム対応に
・Kotlin
・Kotlin 7
・次世代言語21 Go Nim Rust Swift Kotlin TypeScript
・次世代言語28 TypeScript Swift Go Kotlin Rust Nim
・次世代言語24 Go Nim Rust Swift Kotlin TypeScript
・次世代言語23 Go Nim Rust Swift Kotlin TypeScript
・次世代言語29 TypeScript Swift Go Kotlin Rust Nim
・次世代言語25 TypeScript Swift Go Kotlin Rust Nim
・次世代言語議論スレ[Go Rust Kotlin Scala]第4世代 [無断転載禁止]
・【MODARTT】 Pianoteq 2 【Physical modelling】
・Kotlin 8 (234)
・Kotlin初心者質問スレ
・Alice in Chains 2
・ScalaにできてKotlinにできないこと
・●2018年 MotoGP 第6戦 イタリアGP Lap 2
・【スチーム】Steam in Linux 2
・【TOYOTA】セルシオ30系 / LS430オーナー専用スレ 2
・【IT】Kotlinで開発された初のAndroid向け不正アプリが発見
・Led Zeppelin VS Deep Purple 2
・2018年に急成長したプログラミング言語は「Kotlin」「TypeScript」「HCL」
・【EXC】新仮想通貨Excaliburcoin エクスカリバーコイン【えくすこ】 2
・【Netflix】オルタード・カーボン/Altered Carbon 2
・リネージュ2 レボリューション / Lineage2 Revolution Part 282
・リネージュ2 レボリューション / Lineage2 Revolution Part 268
・リネージュ2 レボリューション / Lineage2 Revolution Part 278
・【糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 208
・【糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 205
・【糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 209
・【糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 206
・【糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 207
・【糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 210
・【糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 208
・【糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 215
・【糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 212
・【糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 214
・【糞糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 229
・【L2R】無課金専用リネージュ2 レボリューション / Lineage2 Revolution Part 20
・【L2R】無課金専用リネージュ2 レボリューション / Lineage2 Revolution Part 21
・【鯖統合不労所得】リネージュ2 レボリューション / Lineage2 Revolution Part 241
・【ヴェンデッタ本スレ】リネージュ2 レボリューション / Lineage2 Revolution Part 271
・リネージュ2 レボリューション / Lineage2 Revolution Part 276【課金パックを買うだけの過疎アプリ】
・LINN 2
17:38:03 up 11 days, 18:41, 0 users, load average: 11.89, 11.10, 10.25
in 0.028815031051636 sec
@0.028815031051636@0b7 on 012507 |