◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:Kotlin 6 YouTube動画>4本 ->画像>4枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1561186797/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう
※前スレ
Kotlin 5
http://2chb.net/r/tech/1544268581/ 仕事で使う android アプリを作ろうと思って
>>7 >「はざめての android プログラミング 第4版」
内容を的確に表したすばらしい表現だと思う
Kotlin 1.3.40 released
https://blog.jetbrains.com/kotlin/2019/06/kotlin-1-3-40-released/ Kotlin/Nativeのメモリマネージャ周りの改良により
パフォーマンスが2倍程度向上したそうだ
そろそろ言語機能はいいからライブラリ充実させてほしいわ
Kotlinコンパイラのセルフホスティングを完成してほしい
>>16 roadmapを見る限り、やるべきことが山積みで先は長そうだ。
まぁ出して欲しいとか言いつつまだ出せる状況じゃないのは分かる
>>11 こんなのが出る。
$ kotlinc
exception: java.lang.NoClassDefFoundError: org/jline/reader/LineReaderBuilder
(以下略)
これだな。
https://youtrack.jetbrains.com/issue/KT-32085 >>19 5000兆円あればStable版も夢ではない気がする。
Ktor, KotlinどころかJVMの仕様から作り直しても余りそう。
人生100年として、１秒間に約158万円使える額だ。
5000兆円あったらさすがにエンジニアやめて田舎の山奥で陶芸家にでもなるわ
>>29 誤爆ついでに乗ると俺も有安推しだったから今はソロの方応援してる
>>24 そして自ら田畑を耕し自給自足して金を一切使わない。
>>31 いや、5000兆円の札束を窯焼きの燃料にする
>>33 お札（日本銀行券）は破損しても逮捕されないよ。
逮捕されるのはお金（硬貨）の方だ。
5000兆円を1万円札にしたら50万トン
おれのビットコインなら0gだかそろそろ値が落ちそうだ
お札を数珠繋ぎにして裸で首輪ってのが今のトレンドらしいが
5000兆円だと100万円の札束を数珠繋にして地球と月とを往復できる長さ。
5000兆円手に入ったらこのスレの住人に1兆円ずつ分配するわ
まず金にものを言わせてロビー活動をして日本政府に1000兆円札を作らせる。
5000兆円を預金できる銀行はあるのだろうか?
例え話で出したつもりが5000兆円の話になってて草
>>44 スイス銀行なら大丈夫な感じするな。
無理なら複数の銀行に分散したり自分で銀行作ったりするしかないかな。
自分で銀行作るのが最良だな
>>40 > お札を数珠繋ぎにして裸で首輪ってのが今のトレンドらしいが
kwsk
専業主婦27歳結婚5年目の実態
そういやアクセス集中でサーバが重くて会員登録中々できないと今話題のファミペイアプリはアプリについて出すと先頭に Kotlin と出て来たよ。
今更Androidアプリをjavaで書く奴なんていないだろ
ファミペイは今日、テレビでやってた
ところが今はチャージがファミマのレジでの現金チャージかファミマTカードのクレジットカードでしかできない。
7月中にチャージすれば、還元率は現金チャージで10%（上限2,000円）、
>>51 2019年の新規開発ならそらそうだろとしか
この手のものの開発は1.5年はかかりそうだが・・・
>>53 15%と聞いて飛びつきそうになったが、上限3,000円ということは450円分。
500ポイントプレゼントにすら劣るわけで、一瞬騙されそうになって自己嫌悪。
いやーしかし、この頃なんとかペイが増えて俺のスマホも関連アプリだらけになったよ。
Androidのアプリを作りたいと思っている一般人ですが、現状Kotlinが最適解なんですかね？
>>61 Kotlinは言語としては超複雑な部類で初心者向けの情報も少ないから初学者にはお勧めできない
まずはJavaの入門書を一冊終えよう
Kotlinは割とプロ仕様、ただ動かすだけならすっきりしていて良い言語だと思う
最初から kotlin やるならどうしたらいいですか
>>65 普通に入門書読めば？
またはネットで検索しまくって調べる。
>>68 お前の使い道が無くて干されただけじゃね？
まだある。特に歴史のあるサービスだと新規部分はKotlinでも既存Javaコードはそうそうなくならない。
>>65 速習 Kotlin
俺、Paperwhiteにdownloadしたけど、まだ最初読んだだけ。
固定レイアウトではなくflow layoutなのもGood.
>>70 Kotlinコンパイラ自体がその状態だから困るｗ
javaだろ。データが魔改造したstrutsらしいし。
というかそもそもあれは仕様が頭おかしいだけで実装言語は関係ないだろww
Kotlinさえ使っていれば・・・
エルビス演算子のあとってrunとletどれがいいんですか
もしかしてデータ担当の大手企業って全部魔改造struts1の可能性ないですか
もう死んでるけどNTTデータとかいうネクロマンサーが独自パッチを当てて使い続けてるそうだ
>>81 もしかしてエルヴィス演算子?:じゃなくてSafe Calls ?.のこと?
>>87 別にラムダ式の中でthisが使いたいならrunでいいんじゃないかと。
run/apply を選択する時は let/also における it を省略したい時
>>87 凡ミスのリスクが上がるからDSLの文脈以外では
thisを差し替えるラムダはおすすめ出来ない
別言語での例として、JavaScriptのアロー関数式もfunction式と異なり
thisを差し替えないことが利点の一つとなっている
>>90 applyの方が単語の意味的にコードの意図が明確になる気がするから好きなんだけど、そのローカル変数と名前被り問題がネックだわな。
だったらrunとかalsoとか文法から消せばいいのに
alsoじゃなくてapplyか
T.run, with, applyは実際消したほうがいい
ちょっとしたシンタックスシュガーのせいでバグりやすい仕組みを作ったので、今度は曖昧さを無くすために明示的な記述を強制するターンだぞ
apply はインスタンス化した後にそれに対する設定が書けるので便利
>>95 レシーバ無しのrun{ ... }は{ ... }()でも書けるからやはりいらないのでは。
>>94 自分はスコープ関数早見表をブックマークしてる。
>>96 Effective Kotlinが出版されたら「itやthisよりも明示的な引数名を使う」が多分入ると思う。
>>100 ↓のコードの run{ ... } を { ... }() に置き換えてビルドすれば違いが分かるはず
https://paiza.io/projects/TL1UeckyJ8oSVbRwNo9t_Q?language=kotlin これらはインラインかどうかとトレイリングラムダの性質による
そこらへんは実装時にちゃんと統制取れずグダグダと追加しちゃった感じあるよな
でも言語そのものではなく言語仕様に則って誰でも作れてしまう拡張関数だからな。標準的なライブラリに含めなくても何れ誰かが作っちゃうのではないかな。(それなら使用頻度が少ないから良いのかも知れないが)。
>>105 「Xamarinほどの～」は止めてそれを繰り返すことにしたの？
確かに拡張関数が言語標準じゃなくて社内の誰かが勝手に作ってプルリク出してきてたらリジェクトするな、たぶん
>>109 .also()が出来た理由が、ネストしたラムダ式の中で、itとthis両方を同時に使って引数名を
省略できるようににするためとかいう話があった気がするから、言語の方針として諦めざるを得ない...?
>>110 あー、そういうことなのか
言われればわかるけど、なんというか、その場しのぎ感が否めないな
Androidだけじゃなくて、サーバー側も勉強しようと思って
このスレで聞くならサーバーサイドもKotlinで書けよ。
時期早々なんで試してないんだけど、aws lambda にkotlin native乗せて遊んでみてほしい。
そうだ。このスレにおいては何もかも Kotlin にするのが正しい。
やあ、ことりんだよー
URLがザマリンじゃねーか
kotlin 1.0 + spring boot 1.4 ぐらいの時から何の問題も無かったぞ
そう言えばkotlinにはマスコットキャラいないの？
>>124 なぜにKotlinの後継にしたし。
"Kotlin Class" Destroyer だけど、どうしても Kotlin "Class Destroyer" に見えてしまう。
デストラクタ的な何か。
ことりん覚えるのって公式サイト見るのが一番ええんか？
公式サイト見ながらIntelliJで実際に書いてみるのが一番かな
Xamarin程の糞はない
try kotlin で IntelliJ 無しでも勉強できんじゃね
>>130 このスレに昔からあるネタだから真面目に反応しなくていいぞ
🔹Part 1傾向、正解のパターン(%)
1. 現在進行形 65
The trains are pulling into the Park Station.
2. 受動態 25
The vehicles are parked in front of the townhouses.
3. その他 10
There is/are
is/are being Vpp
has/have been Vpp
The cars are being parked alone the road.
VIDEO >>133 どうやら、is/are being Vppは動作を表すみたいだ。
e.g.
The potted plant is being placed under the picture.
そろそろkotlin nativeのコンパイル速くなった？
CoroutineとRxはどう使い分けるんだろう。
そういやコルーチンって中でどうやって実現してるの？見た目スレッドとほぼ同じ動きになってるようだけど。
>>141 >>140 過渡期
目的によるけど、正直今となってはRxを新しく使う必要はあまりない
ただし例えばスマホでRxSwiftに慣れてるメンバーがAndroidも作るならRxの方が良いとか色々ある
java.beans.XMLEncoder や java.beans.XMLDecoder で XML 読み書きする場合に、書くのは出来ても読む時にクラスないって出て読めない。
エラーが起きる最小コードを作って
>>146 せめてコードとエラーを貼ってくれないと
なんとなくだけど、import書き忘れとかの本当にしょうもない理由な気はする
実行時にうまく行くパターンとダメなパターンがあることがわかった。
(というかむしろ自分でうまく行かないパターンをピンポイントで選んで実行していたような感じorz)
https://paiza.io/projects/6UeOmsYQMaYqbOlaYlvB-w 見ての通り paiza.io ではうまく行く。
その他、IntelliJ IDEA の Kotlin でもうまく行く。
コマンドラインで
kotlinc -d xmltest.jar -include-runtime xmltest.kt
java -jar xmltest.jar
でもうまく行く。
駄目パターンはこれだ。
・ コマンドラインから kotlinc -d xmltest.jar -include-runtime xmltest.kt でコンパイル後に
kotlin xmltest.jar で実行。
・ コマンドラインから kotlinc xmltest.kt でコンパイル後に kotlin XmltestKt で実行。
すると java.lang.ClassNotFoundException: TestData を皮切りに色々と出てくる。
XMLDecoder#readObject() 実行時にクラスが見つからなっていて、要するに kotlin コマンド
内でセットしている CLASSPATH の問題なんだろうとは思うが、直前に writeObject() で
使っているクラスが直後の readObject() で見つからないという謎の状態だ。
(まあ、kotlin コマンドの中を延々と調べて行けば何れ分かるんだろうけどね・・・)。
またkotlinc君か
趣味でやってるならどうでもいいけど業務でそんな無駄なことしてたら引っ叩くわ
Set<K>とSet<V>からMap<K, V>を作りたいんだけどいい方法ある？ (両方のSetは同じサイズ)
>>164 ど、いい方法ある？(両方のSetは同じサイズ)
>>165 LinkedHashSetかTreeSetにように順序付けがあるならいいけど
単にSetとして考えるなら順序不定だから2つのSetの関連付けが出来ない
仕様の前提から考え直したほうが良い
一応順序があるなら m = setK.zip(setV).associate{it} で出来る
今コード書いていて疑問に思ったんだけど、String#sliceとString#substringって何が違うの?
あー。しかしちょっと違うね。CharSequence と String の違いか。
String#slice -> String もあるよ
挙動に差があるようだけど実用上意味があるかは微妙だな
https://ideone.com/lIfuV9 fun ck(nm:String, f:()->String){
try { println("${nm} = ${f()}") }
catch(t:Throwable){ println("${nm} throw ${t}") }
}
fun ck(r:IntRange){
ck("su(${r})"){ "0123456789".substring(r) }
ck("sl(${r})"){ "0123456789".slice(r) }
}
ck(1..3)
ck(3..1)
ck(-2..-4)
ck(1..-1)
ck(-1..1)
ck(8..12)
ck(-4..-2)
この並存状態と微妙な差はJavaScriptの現状に倣ったんじゃないかな
>>172 どうでもいいけどすごく読みにくいコードを書きそうな人だね
コードが読みにくいというか命名が15年前のセンスだと思う
>>176 書き捨てなのと5chの制限回避で文字数・行数圧縮してるんすよ・・・
2文字以下で現代的(？)なのがあるならすまん
>>172 ちょっとわかった。ありがとう。
>>173 なんとなくそうかなと思っていたけど、やっぱりJavaScriptとの互換性のためにsliceを導入したのかな。
>>177 中高生...
こういうところもKotlinがとっつきにくいと言われる一因だよな
firebase firestoreを使っていて月額固定のflameプランを契約しているんですが、
サポートに聞いてみたら？
てか読み取り回数すぐ増え過ぎじゃないですか
googleの新しいカモ要員っしょ
オフライン機能ついたデータ同期する場合はfirestore楽なんだけど。
たぶんfirebaseで何ができるのか良く分かってない人なんだよ
これもしかして２５万回超えなかった日の分が
アプリの更新がなかなかすぐにアップされなくなったり
初心者向けの本を買ったんだが、この方が簡単ですとか言いながらガラケー時代の画面を作らせるとんでもない本をつかまされた…
>>195 ぐぐると出てくる
>>196 ガラケー？今さら実行可能な環境がないように思うが。
Androidだけどガラホで画面が狭いだけではなく？
>>197 FF作れないと怒る初心者の方はいまだにいますよ
あーそれ系か。
>>200 尼でもコメントに理解出来ないって書いて評価下げる香具師が多いな
まあ、著者や編集者の力不足で教えるの下手くそな本はあるにはあるよ
造り方が既にそこら中に転がってて後追いで造っても面白くないやろ
後追いいいじゃないか
今からプログラミングを学ぶとしたらjavaよりkotlinのほうがいいよね？
内部DSLで無茶するよりコード生成の方が最終的には小回り効いて好きだな
>>219 DSLは汎用ライブラリのために丁寧に設計する時用かな。
スキルによるだろうけどDSLのライブラリを使いたいとは思うけど、作りたいとは思わななかった。
もうAndroid Javaの仕事はないぞ
Kotlinでマウントするのはさすがに無理筋
JavaができるならいずれはKotlinもできるようになるだろうがすぐにではない。
実は俺、N88BASIC(86)も使えるんだ(ｷﾘｯ
アセンブラは価値があるかもだな。
Kotlinって結局のところJVM言語のひとつなんじゃない
javaはkotlinに変換できるのに
>>231 できると思うよ。
kotlin→jvmコード→逆コンパイル
逆コンパイルしたやつってかなり非効率なコードしてそう
あ、すまん、回答ありがと
Kotlin使ってもなおスパゲッティになるようならJavaに変換したらもっと凄いスパゲッティになるのではないか？
Javaで書くと冗長な感じになる表現を小さくまとめられる事が多いしKotlinはそういうのも目標にして作られた言語だからな。
作るのはまだjavaでいいだろうけどkotlinをネイティブで読めるようにはなりたい
Java読むよりKotlin読む方がすんなり入ってくる
>>240 完成品はね
でも製作途中で何処かがおかしいんですとか相談に来られても見れない
javaをkotlinに変換すると大体２０%ぐらい減る
開発中の任意のタイミングでKotlinの方が分かりやすいと思うけど
今まで買ったjavaの本、全部kotlinにならないかなぁ…
java見ながらkotlinにして書いてると
書きやすい方からでいいよ
速習 Kotlin: Javaより簡単！新Android開発言語を今すぐマスター 速習シリーズ Kindle版
KotlinはSwiftに似てると思ってたが、言語仕様はSwiftに比べてコンパクトだった。
>>251 Genericsの汎用型、型パラメータの書き方はKotlinの方が好みだな。
e.g.
interface ISome<T: U> {…}
他言語プログラマのためのKotlin基礎 Kindle版
漏れのフレームワーク本の著者の評価では、
英語の本でいいのある？
あ、kotlinの英語の本です
>>256 漏れなんて言い方久しぶりに見たよ（藁）
>>256 >掌田
この人の本、めったに当たりが無い。
Rubyの本は良かったな。特に、CGIの部分。Rails出現以前の本だった。
この本でhttpdがCGIをどう扱ってるか理解した。
httpのputリクエストのrequest headerをRubyアプリは、stdinから取り込むと知ったのだ。
それまでコマンドライン引数でrequest headerを受け取るのか？
はたまた、環境変数で受け取るのか不思議だったのだ。
>>262 言語は関係ない。とにかく標準入力から読めば良いのだ。
つのだは糞
>>253 この本、Win10環境で、Kotlinソースをコンパイルする方法が、巻末にあって良い！おまけにsource code download serviceもいい感じ。
Macbook Proをお布施代として払うのはこれからは遠慮したいし。
もう一冊の本、>他言語プログラマのためのKotlin基礎 Kindle版
こいつは、InteliJ IDEAだかなんだかのinstall方法からの説明で、思いやられる。
おれは、Vim + quickrun.vimで動かしたいのだ。おまけに、書籍掲載のソースのdownloadサービスも無し。
>>266 他言語…本は、すぐ読めた。山田本には無いpackage文の説明があっていい感じ。
package sample.pkg
class Person(val name: String) {…}
って書ける様になるらしい。
それから、
kotlin-prior-learning-book.pdf
へのlinkがあって、これもこれから読んでみる。
>>267 package文でクラス、メソッドをexportして
import文でクラス、メソッドをimportする訳だ。
import sample.pkg.Person
とか
import sample.pkg.*
とか、
import sample.pkg.launch as launch
でlaunch関数の呼び出しをsample.pkg.launchではなくlaunch一発記述OK.
var f = syori()
while (syori() != null){
generateSequence(::syori).forEach { syori2() }
作ればわかる！のkotlin対応版いいね
>>273 >作ればわかる
作ればわかる! Androidプログラミング Kotlin対応 10の実践サンプルで学ぶAndroidアプリ開発入門 単行本（ソフトカバー） – 2019/6/19
>>274 それ
今はAndroidアプリ開発の教科書 kotlin対応 基礎＆応用力をしっかり育成 ってのやってる
実は最初にこっち買った
今なら読める
val adapter = mSpinner.adapter //Spinner
>>275 >Androidアプリ開発の教科書
基礎＆応用力をしっかり育成！Androidアプリ開発の教科書 Kotlin対応 なんちゃって開発者にならないための実践ハンズオン
これ良さそうですね。消費増税前に買っちゃおうかな。
>>277 今年から趣味で休日プログラマー始めた初心者なんだけどSQLサンプルあるから最初にこれ買った
Android studioに慣れてなかったから初心者にはちょっと難しいかな
だから少し慣れた人にお勧め
こういうサンプル書いてある本は実際に動いて満足感得られるし紙上で矢印とかペン入れできるし理解を得るには良いですよね
サンプル載ってる本は他にもjavaも含めて５冊くらい買っちゃった
この一連の自己レス臭い本の宣伝は何なんだ
>>278 解る。
Visual Studio本、多量に買った。▶仕事でGUIアプリ作った。
Xcode本、10冊位買った。▶仕事でアプリ作ったが、職場で採用。
Android Studio本、1冊買った。Yahoo黒帯とか言うやつ▶趣味で始めたが、時間が取れない。◀イマココ
>>276 searchのところは、ArrayAdapter#getPosition(T)がある。
>>273 だけど
もう一度最初からやってみたらビジネスカードのところで躓いた
どうやらandroidXになる前に作ってたぽい
PreperenceManagerがXになって廃止になったとかなんとか、
一応他の方法で回避できたけど全くの初心者はここで立ち止まると思う
>>283 あらら、ダメだ
血圧アプリのRealmの書き方もandroidXに対応してないな
ん～悩む
kotlinのsynchronizedってdeprecatedなんすかね
Kotlinの文字列中に変数かけるやつ
あんなの単なるStringBuilderの構文糖衣じゃん
""に値を設定するんでなく""から外を参照する形になって文字列が文字列じゃなくなった
sh の "～" が遥か昔から中の変数等を展開してくれる仕様
大体の言語には埋め込みと.format呼ぶ2つのやり方があるんだから、簡単に文字列結合したいときと固定フォーマットを定義したいときで使い分けたらいいんじゃないかな？
言いたいことは分かるけど、新しいものを受け入れられなくなるってのはこういうことなんだな、と思った
俺はシェルみたいな埋め込みができて素晴らしいと思ったけどね。
Ruby の文字列・ヒアドキュメント内の式展開だろ。
ERB(埋め込みRuby)と同じ
最初は、HTML の文字列をつなげて、HTMLを作っていたのが、
発想を逆転させて、HTMLの中に、<% ～ %> で、Rubyの式を書けるようにした
<p>
Name: <%=h name %>
</p>
h は、HTMLエスケープをする関数
kotlin nativeが成熟するのはいつなんだろ。。。
try kotlinとかの上に出てくるネコのシルエットって何ですか？
>>304 ギットの猫?
Monalisa モナリサです
∧＿∧ ／￣￣￣￣￣
>>305 ギット？ということで調べて来ました
身体はタコなんですね…w
ありがとうございました
Octocatが名前と思ってたけど種族名だったのか
はじめてのandroidプログラミングのサンプルで使われてるライオンの画像がかわいいｗ
べつにされてもどうってことないよ
kotlinよかJavaの方が汎用性が高いので
そんなもんわからないので俺の主観で直感のみを使ってお答えしよう。
それは無意味な心配だよ
Androidのアプリ開発で使われる事は減るのではないかな。
Android自体がJavaの塊だからサポート外になることはありえないよ
ありえないとは思わんが、もしJavaサポートをAndroidから排除する日がくるとしたら
サポート外にはならなくてもアプリを作る時のJava使用率は減るのではないかな。
どうでもいいでしょ
そしたら Kotlin native なりなんなりそのプラットフォームに合わせたコンパイラ使えば良い。
java知ってるならkotlinは楽
リファレンス様の顔色を窺ってみますと
googleはもうjavaのサポートレベルあげなさそうだよな。
Go当てただけで十分だろ
Googleの言語は理想ばっかりで現実(ライブラリとサポート)が
google天才レベルばかり集めた結果、大多数の凡人が付いてこられなくなった感じはある、なににつけても
IQ150以上の人が作ったものなんて
的外れやな
AndroidのMSスマホだろ？
Googleはデータドリブンに傾倒しすぎた結果、プログラミング言語自体の面白さが生産性を高めないことを確信してしまったんだろう
Swiftのコードを移植しやすくするために、プロトコルを移植する術を用意して欲しいな
>>334 スマホや、インターネット使ってる癖に？w
>>334 今回ノーベル賞貰った人のIQは150未満だったのか？
電池使いやすいぞ。入れとくだけだし。
ま、しかし、大人のIQって一体何を基準にして出すのか謎だな。子供ならまだわかるんだが。
>>341 その前にfunとfuncを統一して欲しかった
いまだにとっさにどちらだか分からなくなる
>>345 そうするって決まってるの？どこで決めた？
偏差値50でIQ100
>>348 そうか。
とりあえずWikipediaで「知能指数」を見てみることをおすすめする。
16歳ぐらいまでしかちゃんとした測定はできないと考えて良い。
>>346 ぱっと見ただけでどの言語のコードかわかるので、悪い話ばかりではない。
kotlinがサーバサイドで動く日は来るのだろうか
ていうかだな、VMのレベルでJavaとの互換性あるんだからJavaでできることはなんでもできるよな。
何で誰もscalaのライブラリ移植してくれないんだ？
>>358 JavaからScalaを呼び出せるはずだから、Kotlinからも呼び出せるのでは?
bit演算子がand/orで、conditionalの方が&&/||って紛らわしいな。
>>360 伝統的に BASIC言語では、and, or が条件分岐(BOOL)用だったので、
混乱しそうですね。
単語と記号の混在が紛らわしいって話でしょ
VBではAndもAndAlsoも、条件分岐用(BOOL系)で、AndAlsoが、
Pythonは、kotlinとは反対だな。
それに、&& や || は長さも & や | より長いので、少し長い and, or と対応し易い。
>>365 誤：世界では沢山入るはず。特にアメリカ。
正：世界では沢山いるはず。特にアメリカ。
and, orは値によっては計算を評価しないというifの役目もしてるから
Kotlinの言語開発者は、andとorは拡張関数で実装すればKotlinの文法の範囲内で文章的に書けると思ったのかも。
ただ、
>>367 が指摘するように拡張関数のand, orは短絡評価がないから
&&, ||とは同じ動作にならない上にパフォーマンスも若干落ちるという残念な仕様に。
将来的に短絡評価するアノテーションとかを作れば何とか出来ると思っているのかいないのか。
>>368 短絡評価しないから残念というものではなく副作用を考えて使い分けるものだよ
だから多くの言語ではわざわざ2種類用意されてる
前段については同意だがやはりなぜ演算子オーバーロードしなかったのか疑問
ビット演算と論理演算の違いって
>>360 が書いてるやろ
ビット演算を短絡評価のない論理演算と捉えてるやつが多くてオシッコちびるわ
ビット演算と論理演算の違いはC C# Javaとかでも同じっすよ
>>369 演算子オーバーロードを許すと、Int, Boolean等以外のLocalDateTimeのようなプリミティブでない
クラスにまでユーザーが論理演算(もしくはビット演算)を定義できてしまうから
好ましくないと思ったのかなと。
>>370 Booleanに限って言えばビット演算と論理演算は(短絡評価を除けば)等価なはず。
Booleanとand, orを組み合わせれば、(短絡評価の問題を除けば) &&, || が不要になる。
>>374 notやplusは演算子オーバーロードしてるのにandがしてないのが疑問だと言っているんだよ
>>375 何を言っても推測にしかならないけど、一つは&&の短絡評価を演算子オーバーロードで再現できないからではと思う。
a && b が bがBooleanかどうかでbが評価されるかどうかが変わるということを避けたかったのではと。
もう一つは、
>>372 の言うように言語仕様を最低限にしようとしたのではと思う。
Kotlinはシフト演算を見る限り、ビット演算しようとする人には優しくない気がする。
>>375 がandでオーバーロードしたかったのが&か&&かはっきりしないけど、少なくともどちらか一つは答えになっているかと。
「演算子オーバーロードしなかった」の意味がよくわからない
演算子がないことを、演算子オーバーロードしてないと言ってるんだろう
https://github.com/Kotlin/KEEP/issues/142 中の人は演算子提供するのに乗り気じゃなさそうだけどそのうち追加されるんじゃないか
shl/shrとかわかりにくいしand/orも他言語から来ると思考ノイズでしかない
ビット演算するとき、|=、&=って激しく便利だし頻出だと思うんだけどなぁ。
そもそも複数のbooleanで扱うべきフラグをビット演算で1つにしてるAPI設計が良くない説
>>380 ハードウェアがそうなってるのだから仕方なかろう。
いっぺんに書き換えないと挙動が変わってしまう
ｊａｖａﾗｰがｺﾄﾘﾝに乗り換える勉強するのにどれくらい移行期間かかります？
超天才でスーパーな人なら入門書パラパラめくって眺めて30分ぐらいかな
java -> kotlin変換しますか？
それだと !! がたくさん残るしそもそもビルド通らない
そっから手直しすればいいんじゃない？？
あれ？forループで変数インクリメントするようなのできねーじゃん。なに？while使ってやれっての？えー！
ていうか for (n in a..b) でもいいのだが、a..b が Range になっててあとはコンパイラが自動でうまいことやってくれる事に気づかなかった。
ひとまず小一時間感覚で書いてみるのは良いとしても
言語リファレンスを一通り流し読みする時間をどこかで確保しないとな
https://kotlinlang.org/docs/reference/idioms.html !!ってダメなのか？
なぜどうしてもそこに必要なのかを説明できない!!は書いてはならない
null許容変数がnullになるかもしれないから!!なんじゃないの？
val a = ThreadLocal<String>().get()
>>400 動作の説明としては全くその通り
しかしそれをコードに適用するデメリットが大きいので全世界中からやめと毛と言われている
>>403 nullになるかも？なだけで実行順を追っていくとならないことが多いからそのままにしている
必要なら対策するけど、ほとんどの場合は実行タイミングに何か値が入ってる
変に怖れて潔癖にならない方がいい
!! は、絶対に、null にならない場合だけに使うべし！
例外が発生するから!!が良くないと考えているならそれはnull安全を履き違えている
!!はforce unwrapと呼ぶべし!!
>>408 Kotlin公式では not-null assertion operator とある
Swiftと合わせた方が分かりやすいとは思うけどな
例えば画像Aを表示する座標x,y
!!を使わなくても安全に実装できるのにあえて!!を使うのは頭が悪いですと言っているようなもの
ファイルヘッダとかにマジック定数あるが、これを表現するには
今はJVM環境で使ってますが、一応コード書くときに、特定のプラットホームに依存しないように書けるとこは書こうと思います
>>411 なぜ使うべきでないのかを説明出来ない限り、議論の出発点にも立っていない
例えば俺は
>>407 で書いた順の通りガード節、requireNotNullの方が
より明示的かつメッセージ付加可能でなので!!より優先すべきと考えるが
本質的には大差無い
NullObjectパターンは有用ではあるが
セーフコールがあるKotlinでは必ずしも必要としない
そのようなケースはnullが正常系の内であるのと同義
>>410 使わない場合はnull、っていうケースは文字通りガード節や?.を使って
nullならなにもしない場合、と同義なのでは
!!を使うべき例としてはピンとこない
!!を使っている関数は引数つまり関数の仕様としては一見null許容型だけど、実装としてはnullを拒絶する不整合がある
何らかの事情で回避が難しいときの苦肉の策で、多用するのは作りが悪いように思う
あとは関数内で既に非nullであることが保証されてるパスの中にいる場合の簡略化で使うか
でもこれを多用するようなら関数が長すぎるという問題を暗に抱えていたり
安全や可読性よりも手抜きを選ぶ悪癖の疑いを感じる
!! null即エラー演算子。
>>414 型安全でないnullを使うこと自体が問題。
!!も、使う前に型安全なnullobjectを検討すべき。
checkNotNull(nullable) { "説明" } がいいんだろうけど、!! で楽したくなる時がある
>>412 byteArrayOf が使いたいって言ってる？
>>410 もし遅延初期化、lateinit が使えるなら、その方がよい
java のライブラリの @Nullable とか、json で条件によって null / not null が切り替わるプロパティとか
>>427 nullableな値を返す外部の関数について、文脈上nullが返らないことが保証できる場合にまで
null対応を書くのは、可読性やパフォーマンスの上で無駄が多いからだと思う。
特にJava(あるいはJavascriptやnative)由来の関数とか。
>>429 誤解されそうなので補足。
1行目の「外部」っていうのは3行目のKotlin外という意味ではなくて、
標準ライブラリを含めて他人が作ったライブラリという意味です。
そのkotlinの存在意義ぶち壊す特異性からしても、どーしても仕方なく使うものであるのだけど
>>426 >>431 requireNotNullは？
1.3.60出てたから久しぶりにkotlin native試してみたらhello,worldのコンパイル時間が更に伸びてた！
実行タイミングが来るまで置いておくだけの関数の中で使う変数は、その関数を実行する前までnullでいいよな？
>>435 型安全が破綻するのでnullobject定義して使っとけ。
>>433 所詮はオモチャなんだからどうでもいいでしょ
JetBrainsとしてもまだコンパイル時間の最適化なんか気にする段階じゃないだろうし
状況が限定されるが、あるクラスがnull相当の状態をとりうるメンバ変数を持っていて
require と check の使い分けちゃんとしとけよ
>>438 オモチャだから発売日が気になっちゃう精神やん
>>435 ものによる。初期化しないとか by lazy にするとか他の方法があるならそちらを使う方が良いかも知れない。
nullのまま素通りさせたくない場合は
!!でなくcheckNotNullやrequireNonNullを使えばOK？
このコードの3つ目のように
https://paiza.io/projects/Ao4mGnYxwoWEuMNRtj_gkg >>438 nullには型チェックが働かないことを忘れちゃいかん。
nullobjectじゃなくてnullがきたときは型チェックでエラーにできるんだから、nullobjectを使ったほうがいい。
!!潔癖症でもいい
Kotlinプログラマーは未だにforce unwrappingの使いどころを知らない
>>444 >432と
>>442 についても意見が欲しい
>>448 nullobjectのデメリットって、null汚染されたクラスの再利用が面倒なことくらいじゃない？
他になんかある？
NullObjectのデメリット？
>>451 オナニーとして気持ちいいなら誰でも使うだろ。
そんなこともわからない無能かぁ……
あるデータが有限の数値をとる場合と
nullセーフな言語におけるNullable型の素晴らしい点は
>>454 requireNotNullやcheckNotNullも同じく台無しにする？
それともこっちは良い？
!!のほうが2文字だし、ここでヌルポが上がるかもと分かるので好き
>>455 何を使うにしても状況に適したものを使えば問題ないと思うよ
>>450 NullObjectはどのような場合でも正しく機能するNullObjectを定義できるなら優れているが、「どのような場合でも」を満たすのは難しい。
null発生の状況が複数ある場合は「どのような場合でも」というい条件を満たすNullObjectが定義可能である保証もない。
最初は条件を満たしていても、プログラムを修正していくうちに条件を満たせない場合が出てくる可能性もある。
しかも「気づかないうちに」そうなっている可能性がありたちが悪い。
条件を満たせない場所だけ分岐させるのは、NullObjectがnullチェック分岐消去を目的にしている
ことを考えると本末転倒な解決策。
APIレスポンスとかデータ定義はNULLじゃない扱いしておいてビルドエラーもでないけど、
すごーく簡略化すれば、
>>459 nullobjectは「賢いnull」なんだから、null的な使い方してもいいだろ。
型安全なnullとして受け取ってnull分岐してもいいしな。
あと、null発生の状況が複数あるなら、それぞれ別のnullobjectにしていいんじゃない？。
Javaではnullobjectを賢いnullとするのは正しいと思う
NullObjectは"Tell, Don't Ask"なクラス設計ではうまく機能するんだけど、
＞もし「nullobjectかどうか」を判定する必要がある場合は
>>465 それなら良いけど、ケースによらずnullの代わりに使うみたいな話の流れだったから
ログインユーザーとかも無効ユーザーオブジェクトになるのかなと
nullの場合の動作を
java脳からkotlin脳へアプデが必要だけど
Null Objectは単なる先送りで、ある意味!!が目指す方向とは真逆。
>>468 >呼び出し側でハンドリングしたくなったら邪魔
型無しのnull使うよりマシだろ。
許容するととんでもないところから紛れ込むnullの方がよっぽど邪魔。
>>471 nullableでnon-nullにできたっけ？
>>472 nullが正常系である場所ではnullabeを使い、nullが紛れ込んだらバグになる場所では非nullを使うって話がもう出てる
適切にゾーニングできているなら紛れ込むことをそう恐れる必要がない
nullという特殊値に対して意識が必要な場所はnullabeという型で言語仕様レベルで明確化でき区別できるからメリットがあり、型無しのnullというほど不便なものでもない
>>465 それがないならNullObjectがいいと思うよ
そこを否定している人はいないはず
ただ多くの人は経験上避けがたいと思ってるから意見が合わないんだろうね
解放閉鎖原則と単一責任原則とで作ってくと最初の動機だけではなかなか完結しない
全部ビジターパターンでとことんNullObject-ableな型にお伺いをたてるように作れば完璧にできるだろうけど、そこまで作り込むコストを考えたら適材適所でnullableを使い分けるのが現実解ってのが落としどころだと思う
Kotlinが選び提供している価値はnullセーフであってnullフリーではないし
NullObjectって非同期呼び出しとかどうすんの
>>473 nullを使っても問題は限定的だと思うけど、あえてnullを使うメリットはあるのかしらん？
実装上の手間が省ける、くらいしかないと思うけど。
>>476 >>438 ,453-454あたりを見てくれ
>>479 freezeによる制限とAPIはKotlin/Nativeのみ
そのせいでマルチプラットフォーム機能がお通夜状態
だから考え直せ
> This is the work of “top-level objects are frozen by default” and “a frozen datum cannot be mutated”.
kotlinてクラス変数に型推論使えるの？
>>483 できるのか！ これができるとリフレクションを使ったフレームワークに幅が広がりそうだよねえ
特定の変数名をもつオブジェクトに値を代入するとかさ
Kotlin 1.4以降に何を期待するか
https://blog.jetbrains.com/kotlin/2019/12/what-to-expect-in-kotlin-1-4-and-beyond/ 品質とパフォーマンスに焦点を当て
大きな機能追加よりエクスペリエンスを向上させること（小さな機能追加はある）
Trailing Commaはありがたい
GitHub統計
https://madnight.github.io/githut/ 中々上がらない原因になってそうなのは
・スマホアプリでのクロスプラットフォーム性が他より劣る
・Kotlin/NativeやGraalVMのAOTの性能が
他のGC持ちAOT(Go, C#)に全然追いつけてない
・AltJSとしてはTSに完敗
・Javaが割とモダン化していってる
kotlin/jsは可能性がなさすぎるから諦めて他のとこにリソース使ってほしい。。
nativeでクロスプラットフォーム狙うならリッチな標準クラスライブラリがないと駄目だろ。言語だけ用意されても。
どうする気もないでしょ
クロスプラットフォームがこんなに早く普及し始めるとはのぉ。
ＪａｖａでWindowsで開発してlinuxでうごかしとる
Kotlin/Nativeってバージョン番号が1.0を越えてるけど、
クラスのnullableなインスタンスプロパティが複数(a,b,c)あって、
小手先のテクニックよりも設計を見直すべきでは
MVVMのViewModelつくったことないの?
>>498 いや、なんでa, b, cをわざわざ別個の変数に代入し直す必要があるの？
そこMVVM云々の事情は無関係だよね
HogeModel(a!!, b!!, c!!).execute()とかなら別に違和感ないやろ
普通のクラスだとこんなことにならんが、複雑に状態が遷移するViewModelだとこんなことになる。
>>499 ああ、!!排除するために内部でそのために別のクラスに追い出せってことかなるほど。
つか、そのためだけならクラスを別に用意するんじゃなくてもいいんだよな。
nullチェックのガード節後に、スマートキャストが効けばいいわけだな
みなさん
>>509 え？
Kotlinって言語の事じゃなかったんですか！？
てっきり言語かと
やっぱりプログラミング言語で合ってるじゃないですか
kotlin始めましたならわかる
>>513 でもまだ本が届いてないんです！
かといってプロゲートを調べたらKotlinがないしドットインストールを調べたらクッソ高ぇし
ヨ■■■で
作って楽しむプログラミング Androidアプリ超入門―Android Studio3.3 & Kotlin1.3で学ぶはじめてのスマホアプリ作成
って本をポチりました
>>513 こんな状態で僕はKotlinを始めている事になるのでしょうか！？
>>516 なってるよ
だからもう書き込まないでね
>>514 そんなこと書いた張り紙がラーメン屋にさりげなく貼られてたらどうしよう
>>509 すいませんでした
調べたらKotlinの源がJavaという事が判明しました
NGIDを解除しました
ですから今はまずプロゲートでJavaをやってます
オンライン講座やアプリにカネをかけたら負けだと思っているのでJavaの本もポチりました
各言語のスッキリシリーズを生み出した、伝説の本！
>>515 たぶん開発環境があってないから楽しめないと思う
サンプル系の本は苦しみながら修正して作るものだと覚悟して望んでください
そうすればとてもいい本です
>>522 そういや動画はわかりやすいと誰かが書いてたな。俺はわざわざ動画探して見ないけど。
手動かしてたら覚える
勉強してプログラミングを覚えてからアプリを作るっていう考えがそもそも間違い
まあ、そう言わんでも
回転機能とワイヤーフレーム３Ｄでドヤってたら
大体アプリを作るのに必要な知識って言語の文法だけじゃない
さっき気がついたんだけど
1.4でkotlin/nativeが爆速になってgoが死亡する世界線に行きたい
誰かが１０００億円の間違いしなかった世界がいい
>>528 その通り。
まあしかしそれ言ったら学校教育は完全にダメだね。
>>533 俺は変な感じがしない。なぜならJavaの頃からそのように使っているからだ。というかむしろそうでない方に違和感がある。
>>538 本人ではないが
>>536 はJavaに最初からnulll(=１０００億円の間違い)がなかった世界線に行きたいらしい。
union って、C言語の union のこと? そういうのはないね。自分で無理矢理 Byte 配列に詰め込むのなら出来るが。
こういうやつでしょ
sealed class Either<L, R>{
class Left<L, R>(val value: L): Either<L, R>()
class Right<L, R>(val value: R): Either<L, R>()
}
var a: Either<String, List<Int>> = Either.Left(“foo”)
https://pl.kotl.in/1oWpsAGCs KotlinはJavaの足枷が重いから劇的に使いやすくなることはなさそう
Union typeをサポートするとString?型もString | nullの略記でしかなくなるのだろうか
Unitと同じくオブジェクト宣言にすれば型としても値としても使える
sealed classってinterfaceを持たないfinalなクラスをEither型には出来ないってことであってる?
あけましておめでとうございます。
大学のC言語の授業で2分木の深さ優先探索と幅優先探索を再帰関数で書かされたなあ
言語の名前がかわいいというだけの理由でkotlinを勉強し始めました。
PCの気晴らし2Dゲームやスマホアプリやかんたんゲーム作ろうかなーと思ってKotlin始めたのだけど、
C#相手だと言語的なアドバンテージはほとんど無いから勝ち目はないわな
要は「めっちゃ書きやすいJava」なので、Javaのときに特段盛り上がってなかった分野はKotlinでも特段盛り上がってはいない
レベルS プラットフォームを問わずKotlinが広く利用される
Javaやってたら取っつきやすいみたいな扱いされてるけどC#の方が覚えやすくね？
kotlinってandroid専用言語という位置づけだと思っていいですか？
現状ではandroid専用。Java代替目指してる言語だからwebで使うポテンシャルはあるけど、その用途で流行ってるとは言い難い。
ま、しかし、みんながやってると自分もやるみたいなのはやはり日本人的な感じがするな。
「〇〇を作りたいのでKotlinを使う」の〇〇に入るのは非ゲームAndroidアプリ、ではある
>>574 欧米の人って明確な目的があって、それに合う道具なら古いものも新しいものも使う印象
日本列島に生息するアーリーアダプタ猿はたいてい手段と目的が逆転していて、
新しいものを触っても「やってみた」で終わるからそれ以上の発展がない
有名人が使ってるから使おう・それが正しいみたいのがあるね
>>577 その後誰も使わなくなるものに手を出して半年で天を仰ぐ事例は事欠かない
だったらちょっとか有名人にも頼りたくなるというものだ
その、「失敗したらどうしよう・・失敗しないように安全パイを狙おう」ていう発想が日本人ていう話
まぁ結局はjavaなんだから、だったらjavaのままでいいじゃんで終わってそう。
webなんかどうでもいい
サーバーサイドがDB直結で済むようなアプリなんてミニゲームくらいだろ
firestoreってrate limitやIP banみたいなこと課金なしにできないの?
貧乏人のくせにうるせえな
まあ、金払って押しつけるのが正しくはある
flutterきてるからもう色々諦めて、サーバーサイドkotlinに注力して欲しい。。
クロスプラットフォームは全部糞
そもそもDartが糞
ちょうど今日はてぶでflutterの記事を読んだがやっぱりDartが糞
https://hachibeechan.hateblo.jp/entry/flutter-is-great-good-but-dart-is-dirt 結局サンプルアプリみたいな見た目のしょぼいごみアプリしか作れないのがオチ
Dartが糞なのはわかる。でもflutterがきてるのも事実。
と思うけど、googleはなぜかKotlin版flutterのJetpack Composeを今年ベータリリース?に向けて作業中。
まぁ、composeはクロスプラットホームにならなくてもcomposeの存在はかなりflutterへの移行を押し留めることになりそう。
K/JVMとK/Nチームがあまり仲良くない感じだったし
相変わらず世間で流行るかどうかばかりを気にしている。世間に依存して頼りすぎている。その結果振り回され続けてしまう。
俺なんて世間の流行なんか無視して我が道をいってるから
趣味なら何でもいいんだろうけど仕事なら需要を考慮しないと糞仕事で薄給とかやってられないでしょ
流行ってるやつの方が情報多くて学習し易いというのはあるな。
>>602 給料あげたかったら、プログラマーは卒業しないとね
>>601 自分が楽しめるならレガシーシステムのお守役としてニッチ極めるのは全然ありだべ
exposedのDAOとDSLってどっち使った方がいいんですか？
流行るか流行らないなんてどうでもいいんだよ
KotlinのコンパイラはKotlinで書かれてるの？それともJava?
Javaに決まっているだろ
コンパイラがどの言語で書かれてるかを質問する人よくいるけど
>>615 最初はJavaで次からはKotlinに変換して自分で自分を記述する状態にしてるかもよ。するとその後はずっとKotlinでKotlinを書く状態になる。
昔はPASCALをPASCALで書いてハンドコンパイルしてから自身をコンパイルさせるなんての本当にあったようだけどな。
>>616 コンパイラを作れる言語かどうかがわかる。
ということ以外の意味はないかな。
最初は別言語で書かれるが、その後自身の言語で書き直すことはよくある
>>618 KotlinのコンパイラがJavaで作られたとしても
Kotlinがコンパイラを作れない言語ということにはならないと思うんだが
美人のまんこと豚のまんことどっちが良いかって豚の方が名器なら豚を選べば良い
>>621 が童貞だとしても、
>>621 が性的不能ということにはならない
つまりこういうことだ
kotlin1.4の展望を読んだんだけど、
いままでバックエンドにIL採用してなかったのは不仲が原因・・・？
今日もnull安全だから…プロパティに代入して欲しいの
近所の本屋ではkotlinの棚にflutterが侵食してきている
／/
通話中でもバックグランドで処理するアプリとか、スマートウォッチ向けアプリ作ってみたい
>>639 どうぞ。遠慮なく。思う存分作ってよいぞ。どんどん作ってくれたまへ。
大丈夫。お前ならできる。俺は信じてるぞ。
完成したらその事を本に書いて出せ。
スマートキャストで、これは問題なくできる。
val x: Any = 0.3
if (x is Double) println(x + 0.2)
しかしこれはできなかった。
val x2: List<Any> = listOf(0.3)
if (x2[0] is Double) println(x2[0] + 0.2)
足し算する前に as Double でキャストすると問題なし。
if (x2[0] is Double) println(x2[0] as Double + 0.2)
なんで? val で List だから内容が変更されることはない筈で、スマートキャストできそうに見えるんだけど。
Listの中身まで推論してられっかボケってこと？
Listに色々なクラスのインスタンス入れて返すメソッドを思い付いたのだがKotlinはスマートキャスト使えるから楽に書けるかなと思ったんだよね。
>>650 [0]は.get(0)のシンタックスシュガー
でgetが要素を変更しない保証がない
covariantの問題だから、将来的にもそこは変わないと思う。
.get()がthisを変更しないことを
> Listに色々なクラスのインスタンス入れて返すメソッド
これのメリットがよく分からんけど List<Any> に対して get(i) + cast する拡張関数作ればいいんじゃね
リストにいろいろと聞くとつい、生Listを構造体代わりにする昔ながらのクソコードを思い出す
>>650 >>654 メソッドを2回呼んで同じ値を返す保証は結構難しい
言語レベルでのメモ化や参照透過性、所有権システムなどが必要になる
フロー解析で出来たところでコンパイル可否がlistOfの実装に依存して
柔軟性もコンパイル速度も悪化するから
Kotlinディスカッションに投げても多分改悪判定される
valやletで十分だと思うけどな
>>651 型チェック＋処理を頻繁に書きたいのなら
こういうの用意しておくといいんじゃね
inline fun <reified T> Any?.letif(b:(T)->Unit){ if(this is T) this.let(b) }
fun main() {
val x2: List<Any> = listOf(0.3)
x2[0].letif<Double>{ println(it + 0.2) }
}
>>650 val x2: List<Any> = listOf(0.3)
val x3 = x2[0]
if (x3 is Double) println(x3 + 0.2)
これはスマートキャストいけた。
雑に考察すると、x2の右辺には別スレッドで
val x4: MutableList<Any> = mutableListOf(0.3)
と定義したx4を書くことも出来て、
ifの条件式が評価されてprintlnが実行されるまでに、
元のスレッドでx4[0] = "string"が実行されている可能性が微粒子レベルで存在するのかなと。
data classなんかの読み取り専用プロパティへの参照なら同じ書き方でスマートキャストできる
>>659 あ、そーか。その可能性あるな。
Listの皮を被ったMutableListね。
kotlinはc++みたいな玄人向けのクソ言語になろうとしてるのか?複雑すぎやろ。コルーチンでどうやってエラー伝えればいいんだ
https://qrunch.net/@kyoutoday/entries/64IYC8Ye81WyzA5L >>662 >coroutinesなどで実行している非同期なコードの例外をキャッチすることができません。
どういうこと？出来るだろ？
suspend fun f(): String { throw RuntimeException() }
fun main() {
try { runBlocking { f() } }
catch(e:RuntimeException){ println("catch") }
val d = GlobalScope.async { f() }
try { runBlocking { d.await() } }
catch(e:RuntimeException){ println("catch") }
}
runBlockingって、名前の通りスレッドブロックするん?だったらさすがに実際そんな使わないだろ。launch,asyncなどのコルーチンビルダーで例外キャッチできないと
>>665 基礎無しで応用を全部使おうとして混乱してるように見える
Kotlinに関しては道筋のドキュメント不足が原因かもしれない
> launch,asyncなどのコルーチンビルダーで例外キャッチできないと
C#のasyncやJavaScriptのPromiseでも変わらんよ
言語に限らず非同期処理の基礎知識として
コールバック、待機/通知、イベントループをまず学ぶべき
エラー処理については
>C#のasyncやJavaScriptのPromiseでも変わらんよ
suspend fun fun2() {
と、coroutine境界の内外でどうエラーの例外を伝えればいいか悩んでた次第です・・
>>669 >>664 をC#で書くとこうなる →
https://ideone.com/QwtGY4 try{ GlobalScope.launch {例外発生} } ...
これはスレッドで言えば
try{ Thread {例外発生}.start() } ...
と同じこと
>>668 で書いたように戻り値も例外も同じで
待機やコールバックにより「受け取る」ことが必要
Kotlinでは runBlocking{}
C#では .Resultまたは.Wait() (どちらもスレッドをブロックする)
JavaScript(Promise)ではonRejectedコールバック
>>670 > 他の言語なら普通に例外を伝搬させられる
まずここに勘違いがある
Kotlinに限らず同期メソッドと非同期メソッド間で
待機やコールバック無しに伝搬することは無い
main自体を非同期メソッドにしているか
ブロックする呼び出しをしていることに気付いていないだけ
>>673 うん。だから、他の言語でmainメソッドを非同期メソッドにして、普通にtry-catchで
例外捕まえれるけど、kotlinだと無理だから他の方法あるのかな？？って
話をしてたんですけど・・・
>>674 mainを非同期メソッドにして普通にtry-catch出来るけど
suspend fun fun2() { throw Exception("hoge") }
suspend fun fun1() { fun2() }
suspend fun main() {
try { fun1() }
catch(e:Exception){ println("catch") }
}
躓きの原因になってそうな点を書いてみる
KaMP Kitの紹介 (Kotlin Multiplatform用のツール)
https://blog.jetbrains.com/kotlin/2020/02/accelerate-your-kotlin-multiplatform-evaluation-with-kamp-kit/ 試してないけど、マルチプラットフォームでアプリを作る際の
注意点やどのように書くかのガイドを目的としたツールのようだ
ツール自体ではないけど、ツールを作った会社の人によるKotlin/Nativeでの並行性についての話
VIDEO >>680 ビッグデータはJavaが強い分野で、オワScalaの代替としてKotlinを推すのはわりと自然な戦略
まあJupyterを全面に押し出すのはちょっと的外れだが
>>682 バグかな。1.4リリースまでには抹殺されることを祈る。
valの値がミュータブルオブジェクトだったりするのはありえることだから、常に警戒はしている。
>>682 kotlinのvalは「valで定義されたものに=を使われていたら、コンパイル時にエラー出して止める」というご利益しかないよ
valの前にわざわざopenを書いてる以上、こういう拡張への意図があったということだよ
interface の val も実装を var にできるしな
関数の引数をラムダ式にして、それをnullableにしたいんですがどう書いたらいいですか
fun fuck((abc: () -> Unit)? = null) {
それなら、nullable外してデフォルト値{}がよくない？
尼で検索したら Kotlin の新しい本が出てきた。
>>691 去年に出たのを見ると、超初心者向けのが若干少ない気がするね
Kotlin始めました。導入しましたって話聞く機会が減ってきた悲しい。
結局残るのは考えがしっかりした言語だ
まあC#から拝借した機能の多さを考えるとMSが作ったと言えなくもない
kotlinで関数型を受け付けるメソッドに、特定のクラスのメソッドを渡したいのですがどうすればいいでしょうか？？
Kotlin 1.3.70 Released
>>703 効いたと思うが、他スレッドから変更される可能性があるならダメなのでは？
普通に書いていれば別スレッドから書き換えられるvarにsmartcastはできない
変数にもローカル変数やらいろいろあるし
IntellijでKotlinでJavaコード呼び出した時
Kotlinって単純にJavaの上位互換と考えていいんですかね？
>>712 ・とにかく即動ける開発者を大人数集めないといけない場合
・約1MBのアプリサイズ増加が許容出来ない場合
ならJavaかな
特別な俺に酔いしれる、アートなプログラミングをするスレ民にふさわしいな
異端だな。
アンドロイドアプリ作る案件でしか触ったことないけどアンドロイドアプリ以外でもこの言語使うことってどれくらいあるんだ？
アプリ制作専用言語という認識で差し支えないってことね
2年前くらいの頃はサーバーサイドJavaも食いそうな勢いだったんだけど、見る影もないね
何度も言われてるがベターJavaで、近代Java案件の置き換えが可能なのだが、
javaの上位互換だからjava出来るならKotlinも直ぐ出来るって勘違いしてる人結構いるけど、
Javaはお固い分野でも新規に使われてるのに
Java＜kotlinだけどそもそも新規でのJava需要が下がってきてるから流行らないって事か？
>>726 「新規に使われてる」の解釈が違う
文字通りの意味じゃない
>>727 Java<Kotlinな業界ではサーバーサイドJVMは落ち目だね
世間一般には圧倒的にJava>Kotlin
>>728 どういうこと？
否定をするなら解説込みで欲しい
かつてJavaは凄く人気が有った言語だから、エコシステムが物凄く大きい。
エンタープライズでJavaを採用するような案件や環境は安定と安心が最優先すぎるのが逆風だと思う
エンタープライズではテストと比べればコーディングの手間は無視できるし、
KotlinはJavaとは宣言の書き方が前後逆になっただけの様な言語のイメージ。
>>733 短い簡単なプログラムなら、習いたての新しい言語でも作れるが、長くて複雑なプログラムには、十分に時間をかけて習熟した言語でないと作るのは難しい。
次々に生まれる新しい言語をニワカに学んでもいいプログラムを作るのは難しいのだ。
新しい言語では逆に間違ってしまったり、やりたいことを実現する方法が分からなくてそれを調べるために効率が下がることが多い。
Javaの言語仕様は、人気が有ったことからも分かるように昔から既に優れており、それはそれで一つの完成系をなしている。
根本的に新しい言語は一部だけは優れていても、どこかではむしろ劣っていることが多い。
一方でJavaはJavaで進化し続けている。
そういうことなんだろな。
>>739 そういう観点でいえば、学ぶべきはKotlinじゃなくてGoやC#などの非JVM系言語だろう
Kotlinを選んでいる時点で、自分もまたコンフォートゾーンに留まろうとしている平凡な人間の一員であることを自覚したほうがいいぞ
どんなに優秀な人でも、あらゆる言語やツールキットを学ぶほどの時間は無いから、学ぶべきものを取捨選択や優先順位付けが重要。
令和のstaticおじさん(この方はJavaおじさん)かな
ねぇねぇScalaって息してる？Kotlinとどっちがすごい？
息はしているがどっちが凄いかは知らん
ScalaのコードをJavaScriptのコードに変換する「Scala.js 1.0」リリース
https://thinkit.co.jp/news/bn/17374 >>743 何でも学べばよいと言うわけではない。
優先順位を付けられない人は非効率。
>>746 というか、新しい言語を学んで無い人を馬鹿にするのは良くない。
自然法則は昔からずっと変化しないから学んで損は無いが、言語は人工的なため、不変性も無く学ぶ価値の無いものも多数含まれる。
その取捨選択が重要。
少なくとも多言語のスレでJAVAだけでいいんだ！って力説されてもね
Kotlinが蔓延することで困る人もいるんだから。
>>748 ネットではKotlinそのものに価値があるようなことを言う人を良く見かけるが、実際はGoogleがOracleとの訴訟に負けて、Javaを使っていることを注意されて、それで使われるようになっただけの言語、と捉えるのが標準見解だ。
>>734 > Javaなら、Swingを使えば、Win/Mac/Linuxで共通アプリが作れる。
Javaのライブラリ使うならKotlinでもできることになるが？
>>736 わかった。それじゃあかれこれ30年ぐらい使い続けているPerlと35年ぐらい使い続けているC言語を使うことにするよ。Javaのような新言語に手を出すのは止めておこう。
>>754 別にそれでいいんじゃない。
俺はJavaの回し者でもなんでもないからな。
>>736 そういう観点なら、better javaのkotlinを学習する費用対効果は大きい。
実際、自分でクラスを設計するのならnull freeにできるkotlinの価値は高い。
……というより、型無しのnullを排除できないjavaの型システムが破綻しているだけだけどな。いいかげん、nullを受け付けないクラス／変数に対応してほしいぜ。
>>756 むしろ、null を使うことは美しいと思っている。
引数にnullを渡すかどうかで動作を変えられることは、プログラミングの中でも最もスマートな方法。
でも、いざnull safetyの言語使ってみると!!演算子使う自分のコードが気になって負けた気になる
!!は便利だけど後で見返すと消したくなるわ
>>756 JDK25ぐらいでなんとかならんのかな
Javaできるならサンプル見ただけでなんとなく使える
当然、Kotlin の会長である太郎本！
>>763 本読まなきゃいけない奴が手を出す言語ではない(ドヤァ)
キモすぎアホすぎて草
んなこと誰も聞いてねえってのw
質問に答えてやれよカス
そもそも仕事だったら新規言語に手を出す出さないは個人の判断関係なく強いられることもあるだろうw
それともニートか？お前w
>>762 完全初心者なら
>>273-275 あたりで出てる本がいいんじゃないかな
>>763 サンプルコピペして使えた気になってるコピペプログラマーの典型みたいなこと言っててワロタ
有名な雑食系エンジニア・KENTA も、YouTube で言ってたけど、
>>767 言語外の仕様か。いくらか眉唾だが興味深い。
雑食系エンジニア・KENTA
Scalaが日本で衰退し始めている理由を説明します
VIDEO 動画で食ってる奴がエンジニアを名乗る不思議な世の中
>>767-769 なるほど
KENTAはクソだけど内容は腑に落ちる部分があるな
>>757 Kotlinでそのようにしたければそのように書けば良い。できないわけではない。使い分けできて尚且つコンパイル時のチェックが厳しいだけ。
ここの人はjavaを触る前にkotlin触った人いる？
要するに、複雑なものは習得コストが高いから、暇人しか集まらないようになる。
>>776 長くなったのに
>>767 の最初の2行しか説明できてない。残念。
KENTAがRuby推しということはわかった。
>>757 型自体の操作(メタプログラミングとか)ならともかく、まずはクラスの中での操作を考えるべき。多態とかnull objectとか。
javaで一番多いトラブルはヌルポだろ。本来なら真っ先に対策すべきだと思うがね。
>>779 なんで頓珍漢な流れになってるんだ
ネットでドヤ顔したりマウント取ったりするには有用な知識
>>785 特殊な場合があるときにそれを-1とかで表すよりも100億倍まし
特殊な場合がないのにnullableにするのは論外
何も考えず!!演算子を使うのも論外
NullObjectを作るかどうかはメリットデメリットあるのでケースバイケース
脳死で作るのはJavaでenumを使わずにTypesafe enumパターンを手書きするような冗長さになることもあるし
下手に使うと-1と同じ弱点を埋め込む場合もある
nullに忌避感がある人はこのスレをnullで検索すると議論が参考になるかもしれない
>>757 はKotlinを否定してJavaでnullを扱いたいのか、KotlinのT?型と?.演算子や?:演算子を奨励したいのか
読んでいてよく分からなくなってきた。
>>790 少なくとも
>>781 の内容はnullでやる必要ないよね？って話なんだけど？
あれは特殊な場合なの？
>>792 >>793 >>794 メソッドを引数なしと親ウィンドウ指定ありの2種類にオーバーロードすればいいね
オーバーロードできない言語でも名前を分かりやすいように分ければいい
この場合はnullは使わない方がベター
>>794 >>795 似たような処理を行う関数は、完全に2つに分けてしまうとバグの原因になる。
理由は、内部で似た処理を行っている箇所を両方とも修正する必要が出て来やすくなり、一方だけ修正して他方は修正し忘れたりすることが多くなるから。
こまごまとした違いが有って、一致している部分もあったりするので、単純な機械比較は出来ないので同一性チェックを人間の目で行わなければならなくなる。
だから、
>>793 のように書いたほうがずっと安全になる。
>>797 「親が有るかどうか」
という一つのパラメータだけなら、まだ良いが、
「メニューオブジェクトを渡すか渡さないかでメニューが付くかどうか分ける」
なども付いたりすれば、組み合わせ爆発が起きるため、関数を完全に分けてしまうのは非常に非効率で危険なプログラミングとなる。
共通化が必要ならNullObjectの多態でも関数型でも使えばいいよ
組み合わせ爆発についてはデフォルト引数使えばよろし
>>800 そのデフォルト引数には、NULLかNullObjectを指定するしかないはず。
なんで、NULLで済むのにNullObjectを使うの。
それで安全になるのか？
>>799 では、
>>793 の例を NullObjectや多態を使って分かり易くて安全に書き直してみてください。
>>796 すべてのウインドウはRootWindow配下とするみたいなルールを設定して、親のないウインドウは禁止するればいい。
linuxのプロセスが必ずinit配下になるのと同じ感じ。
>>803 それは可能だけど、グラフィックのFrameBufferの容量が大きいので、
デスクトップに浮いているWindowの場合にChildWindowと同じ処理をしたのでは
メモリーの無駄使いになることがあったり、
デスクトップに浮いているWindowとChildWindowとでは動作がかなり違っていたり
することが多いので初期化段階から if 文で場合分けしないと無理が有る事が多い。
だから、そのような「統一した考え」では結局は、効率が下がるために
実際には駄目プログラムとなる。
>>804 さらに付け加えるなら、RootWindow のオブジェクトの名前を「覚えるのが面倒」
だったり、打ち込むのが長くなって大変と言う事情もある。
例えば、Windowの場合には、「DesktopWindow」という名前で、
Menuオブジェクトが無い場合には、「MenuNull」みたいな名前となる。
しかし実際にはこんな簡単な名前で無い事が多いので、マニュアルをいちいち調べ
直す手間がいる。
一方、NULLだといろんな場面全てNULLなので、覚えることが少なくて済むし、
打ち込むにも4文字で済むので楽。
関数を呼び出す際も短いので一行で書ける場合が多くなり、見易い。
>>793 Kotlin ならこんな風にすれば良いんじゃないの?
fun myCreateWindow(parent: CWnd? = null): CWnd = if (parent == null) 親なし上位Window作成 else parentの子Window作成
nullable がどうしても嫌ならこうするか。
fun myCreateWindow(parent: CWnd = 親なし上位Window): CWnd = if (parent != 親なし上位Window) parentの子Window作成 else parent
言語やベンチマークの議論一般にいえることだけど、自分の有利な土俵に引っ張りこめば何とでも主張できる。
Kotlinは
>>805 向けには作られていない。というだけのこと。
>>804 そこはクラス分けてポリモーフィズムで上手くやろうよ
先のウインドウタイトルといい、例が良くないんでは？
>>801 書かれてたサンプルコードでは真っ先に分岐が入ってたから「この場合は」オーバーロードかメソッド分割がベターと回答した
後付けされた条件を加味するなら
>>806 のnullable型がいい
privateな処理内で局所的にnullabeを使うことに異論はない
Kotlinならヌルポが出ないから安全
覚えるのが面倒ということまで気にする公開APIなら親にnullを指定すると親無しになるというルールを覚えさせるよりも
親の引数を省略可能にするかメソッド名を用途別に分けてクラス内で処理を共通化した方が使いやすい
nullは単一なので楽という話は、nullは単一なのでいろんな意味がまぜこぜに使われ区別できないという裏返しでもある
variantは型がないので楽、グローバル変数は楽、staticは楽というのに通じる
メソッド引数にnullを与えたときヌルポが出るのかトップレベルウィンドウになるのかドキュメントを読まないと判別できない公開APIは残念
Kotlin では、プログラマーが自分で、null を判断したら、ダメ！
>>811 だったらそもそも静的な型がない上に基本的にプログラマが明示的な型チェックもしないことが普通なRubyは、
Kotlinで常にnull許容でチェックも一切しない以上に遥かにバグが残るってことになる(実際そう)なのだが、
自分で意味分かって言ってんのかなこいつ
「真っ先に条件分岐が入ってたから」
それにそもそもオーバーロードかメソッド分割がベターとかいってるが、設定するメソッドじゃなくて現在設定されてる値を取得するメソッドまたはプロパティを追加するときはいったいどんな値返すんだ??
>>814 nullable使わないなら異なる型を返すんだよ。nullable含め場合分けを型で強制することで不必要なバグが入り込む余地を無くすのがnull safetyな言語の流儀
そういう他人をわざと変な方向に導こうとしてもひっかからんしつまらんから..
>>808 >そこはクラス分けてポリモーフィズムで上手くやろうよ
具体的にポリモーフィオズムでどうやれば分かり易く書き直せるか教えてください。
>>813 どこ行ったの意味がわからない
どこに矛盾を感じたの？
>>814 俺はメリットデメリット考慮してnullableも含めて最適なものを選ぶのがいいと言ってるんだよ
前提が変わればnullableが簡潔で具合いいところもあるだろ
>>794 のサンプルでnullabeを選ぶ理由ある？
>>818 訂正
デフォルト引数の初期値をnullとして使うケースは良かった
理由は上で書いた通り
そもそも null はそんなに危険ではない。
nullが危険といっている人は、MMUを使ってない化石の様なOSでの経験に基づくものなのかな。
if で場合分けせずに、オブジェクトのclassの仮想関数で場合分けさせると言う考え方
ページ違反が起きて特定に悩まされたのが昭和
>>823 むしろ、OOPでやればなんでも上手く行くと思い込んでいる頭の固い馬鹿にしか思えんが。
Javaカスイライラで草
新しくても駄目なものは駄目。
>>828 今時厳密にコーダープログラマーをわけてる現場なんかないだろwクソ老害か？w
>>829 老害イライラで草
顔真っ赤にしてる暇あったらkotlinの勉強しようなwww
>>833 Javaはブームとなるほど、当時としてはちょっと革新的な言語だった。
Kotlinは全然違う。
>>832 君が派遣されてるドカタ現場ではそうなんだね
nullセーフもoopも嫌いならgoがオススメですよ
>>835 君が派遣されてるクソ現場は下流しかやってないから律儀にフロントとバックでコーダープログラマー分けてるんだねw
普通上流の仕事してたらそんな底辺下流の扱いなんか厳密に分けてないよwwwww
勉強になったねえ w
>>829 年寄りだったのか。
若い頃に苦労して身につけたテクニックが、言語仕様でカバーされて誰でも実践できるようになって、
脅かされている自分のアイデンティティを守るために必死になっている、ってところかな。
>>839 この板に居るようなパンチカード(?)を語るようなほどの年寄りではない。
NullObjectでNULLを代用することが、
「言語仕様で誰でも実践できるようになって、自分のアイデンティティーが脅かされる」
に該当するとはとても思えない。
>>840 > この板に居るようなパンチカード(?)を語るようなほどの年寄りではない。
この板にパンチカードなんて単語一度も出てきてないけど誰のこと?
パンチカード世代ではないにしても、NULLを駆使するのが美しいテクニックだった時代の年寄りなんでしょ?
相手の主張を反論しやすいように歪曲するのはやめた方がいいですよ。
>NullObjectでNULLを代用することが、
「NullObjectでNULLを代用すること」はKotlinの言語仕様でないから、
そのように受け取ったのなら、Kotlinのコンセプトを理解していないか、
相手の主張を反論しやすいように歪曲する癖があるかのどちらか。
>>840 が対話の成立しない相手であることが証明されたので
>>840 の回答には大変満足しております。ありがとうございました。
なんだ、親無しWindow を、null にしただけか。
>>820 それどっちかというと Windows 独自の文化だと思う
たまに Windows 系の助っ人に行ってコンソールに例外出まくりなのみてビビるよ
>>843 nullは存在しないことを意味すると考えれば、あながち間違いでもないと思うし、
デフォルト引数を使うにしてもデフォルト値はNullObjectになるだろうし。
というのは置くとして
>>842 で述べたように
>>840 にこれ以上構わないほうがいいと思うんだが。
俺が老人という言葉を使ったのは実年齢のことではなく振る舞いだよ
>>845 あながち間違いでないことと良いAPIであることには隔たりがあると思うよ
参考としてはJavaが提供しているライブラリにおいてnullを指定してくださいというメソッドよりもオーバーロードを提供しているメソッドの方が多い
ウィンドウの例だけでなく一般化して考えると、引数のデフォルト値として空の関数を与えて綺麗に書けるケースも多い
メソッドごとにnullを渡すべきなのか空の関数を渡すべきなのかNullObjectがあるのかを考えず、引数を省略するというシグネチャーで判別可能な一貫した利用ができるのは優れたメソッド設計だと思う
爺さんが引数に null 渡す例出したのに釣られちゃってるけど
プログラマーの気持ち悪い部分をいい感じに体現してくれてる
なんでも古い古いと言っていれば、どんなに駄目でも新しい言語や若い人が有利になってしまう法則。
引数の個数や型だけが異なる「関数の多態性」を行うと、プログラムが間違い易くなる。
>>852 一つの関数名に引数の型や個数が異なる関数が10種類くらい多重定義されていたとする。
これを使ったプログラムする際には、マニュアルを見、関数名だけでなく引数も非常に正確に書かなくてはならなくなる。
型や引数の順序や個数などが僅かでも間違っていると、自分が思っていたのとは違う定義のものが呼び出されてしまうことになるが、それでも「合法」になってしまうのでコンパイラがエラーを出してくれない。
また、後から動作を調べようと思ってマニュアルを見たときにも、見間違いで間違った定義の部分の説明を読んでしまう現象が生じ易くなる。
>>853 func(1,2);
と書いたつもりで、タイプミスなどで
func(1,2,0);
と書いたとしよう。
func()が多重定義されていない場合なら、コンパイラがエラーを出してくれる。
ところが、func()が多重定義されてしまっている場合、たまたま、3つの整数引数の定義があった場合、自分の思ったのとはかなり違う動作の関数なのに、コンパイラが何もエラーを出してくれなくなってしまうことが有り得る。
それから、知らず知らずに「引数の自動型変換」機能が働いてしまうことが有り得る。
それと関数の多重定義の両方が組み合わされると、自分が思っていたのとはかなり
違う動作の関数が間違って呼び出されることになっていても、気づくことができない。
本当はどの関数が呼び出されているのかが分からず、どんなにチェックしても原因が分からない難しいバグが入ってしまうことになるかもしれない。
技術的な話でスレが進むのは、過疎ってるよりは良いことだよ
>>854 その話は、引数爆発は嫌だ、じゃあデフォルト引数使え、で解決してるだろ
さらに付け加えるなら名前付き引数も使え
そのあたりのCやJava時代の弱点をKotlinやC#は克服済みだ
あと多重定義は多態とは呼ばない
>>854 たまたま同じ型ばかりを引数にとる関数で順番を間違えるヒューマンエラーには配慮できるのに、nullを多用したときに誰かがミスして実行時エラーが多発するリスクに目を向けないのは何故？
>>857 >あと多重定義は多態とは呼ばない
異なる型に対する多重定義は多態の一種だよ
>>853 ほんそれ
同じように思ってた人が居て良かった
>>853 混同するのが危険なほど挙動が違うのなら、そもそも同じ関数名を使うべきじゃない。
関数・クラス設計における命名規則の問題だろ。言語設計(javaのヌルポ)の問題と関係ない。
この主張が、なんで型なしnullのマジックナンバー利用の肯定に繋がると考えているの？
>>857 「ポリモーフィズムは次のようないくつかの種類に分けられる：
・アドホック多相（Ad hoc polymorphism）：ある関数が、異なる型の引数に対してそれぞれ異なる実装を持つ場合。多くのプログラミング言語で関数の多重定義としてサポートされる。
・XXXX
・XXXX
・・・
」
>>858 親Windowのポインタを受け取る引数にNULLとした場合、意味は分かり易い。
「親がない」こと以外に意味を取りようがないから。
同様に、メニューオブジェクトへのポインタをNULLとした場合も、
「メニューがない」こと以外に意味を取りようがないので分かり易い。
それに比べて、関数を多重定義した場合には、ミスによってとんでもない動作をしてしまうことが有り得る。
>>864 結局、関数の実装者がミスってnull参照エラーを起こすリスクは見えてないのか
>>865 この例の場合、NULLにすると、それぞれ親Windowがない場合、Menuがない場合で、どちらも重要なので、さすがにテストしてあるはずなのだ。
この例に限らず、引数にNULLを指定する場合は、そのような「重要な変化」をもたらす事が多いので、必ずテスト済みの場合が多い故に安全なことが圧倒的多い。
>>864 何を言いたいのか全然わからん。
NULLの利点は親Windowの指定方法だと言っているのに、
>>854 だと全く関係のない関数funcでoverloadに問題があると言っている。
自分の主張に沿うようにいいとこ取りしすぎ。
同じケースでNULL利用の利点とoverloadの欠点を比較しろよ。
>親Windowのポインタを受け取る引数にNULLとした場合、意味は分かり易い。
nullよりも"NoWindow"というNullObjectを定義して使ったほうが意味はわかりやすい。
なんでnullを使わなきゃいけないのかね？
>>867 後半、NULLで十分なのに敢えて、NoWindow なんてオブジェクトを定義する必要
を感じない。それでバグが減るわけでもないし。
>>866 それは言い換えると、nullを安全に使えるのはテストのパターン漏れがあり得ないような重要な変化があるところに限られ、それ以外で使うと安全とは言えないってことだよな
「安全なことが多い」ってのは危険は残っていると認めてるね
「さすがに～はず」ってのは希望的観測だし、最後の文だけ「圧倒的」を付け足したのも論拠不足だよな
人は多重定義で引数順を間違えるような凡ミスをすると理解できているんだ
では人が重要ではない甘いところでnullを不用意に使ってしまうミスは当然あるよな
>>868 前半の準備できてから議論続けてね。
>「必要を感じない。」
それは個人の感想なので、主張としては弱くて役に立たないですね。
・メソッドを使う時に「NoWindow」であることをより明確化できる。
・間違えて「NoWindow」を指定してもnullより目立つので間違いに気づきやすい。
・名称がより明確なので、第三者がソースコードを読む時に読みやすい。
・それ専用に定義された変数に入っているので、IDEの支援を受けやすい。
・このケースだと必要性は薄いが、nullの意味が複数あるような場合でも(null,undefineなど)別々に定義できる。
くらいの利点はあるけど？
NullObjectパターン使ったライブラリーとかほとんどみかけないから...
GetParentやGetMenuでnullチェックを忘れたらヌルポ
>>871 c言語の悪癖に冒されているだけだろ。
「マジックナンバーは悪」というのは常識だろうにマジックナンバー的にnullを使う設計者の気が知れんわ。
Springもいるんじゃない？
>>873 Keep It Simple.
NULLで現実に全く問題ないのに、NullObjectを導入することで新たな問題をむしろ入り込む余地が生まれる。
Polymorphism というが、「親Windowが無い」「Menuが無い」のような劇的な変化
は、Polymorphismでやるより、その場で if 文で場合分けするほうがプログラミングし易い。
例えば、Polymorphismに向いているのは、動物の種類を分けるようなときで、
「動物そのものが存在しない」時には向いていない。
後者は、if文無しで対処するより、本文の方でif文をちゃんと書いて場合分けした方が間違いが
生じにくくなるし、コード量も少なくなる。
だからNullObjectを使って、NullObject自身に処理を行わせて本文にはif分を使わないより、
ちゃんと本文にif文を書く方が適切なのだ。
仮にNullObjectを使っても結局、本文に if ( pMenu == &NullObject ) などという if 文を
書いてしまっては、Polymorphismにはならないし。
KotlinはNullObjectよりnull推奨で
>>873 NULLは、「無い」という真空状態のようなものに対応している。
(古典物理学的にはだが原則的に)真空は唯一のものであるから、
親ウィンドウがないことと、Menuがないことで、別の真空が存在する
わけではなく、唯一無二の真空で十分だとも考えられる。
それとマジックナンバーでは全く異なる、
マジックナンバーが問題なのは、後で修正しようとした時に簡単に修正できないことや、
その意味での定数を使っている場所をgrep検索で発見できないことだ。
親ウィンドウやMenuが無い事をgrep検索する必要はないし、「無い」状態を
簡単に修正する必要もない。WindowNullやMenuNullと区別した所で何か便利になる
可能性は低い。
マジックナンバーとは、
int TOMATO_PRICE = xxx;
int NUMBER_OF_TOMATO = xxx;
・・・
int TOTAL_PRICE = TOMATO_PRICE * NUMBER_OF_TOMATO + CAROT_PRICE * NUMBER_OF_CAROT;
みたいにしてから、
func(TOTAL_PRICE);
とするのと、いきなり合計価格を計算してしまった結果だけを使って
func(4032);
などとするのでは大きく分かり易さも訂正し易さも変わってくると言うことだ。
この場合、TOMATOの一個当りの値段を変えたり、個数を変えたりすることが、4032という数値では
簡単に修正できなくなってしまうのだ。
そのような問題点は、NULLにはない。
Kotlinってnullableを使っても安全だし
古いものが大好きなnull爺にこの話を教えてやろう
>>880 偉いとされる人が言った、または、有名な団体が作ったようなものを無条件で信じるあなたのような権威主義者が多いだけ。
有名な所が出してきたものは初期の衣の凄くもてはやされる。
使ったこともちゃんと学んだことも無いのに多くの人が褒めちぎる。
それはなぜかというと、そうすることで自分が新しいものに追いついていると
人に錯覚させることが出来ると思い込んでいるからだ。
実際には何も知らないくせに適当に新しいものを褒めているだけ。
null自体が問題なんじゃなくて、既存の言語の型システムでnon nullableな参照型がないのが問題なだけ。ごっちゃにしすぎ。
だから、null自体はあった方が便利、ただ、型システムの方で値型だろうが参照型だろうがnullable、non-nullableの両方定義できるようにしとけってだけ
>>880 その失敗の本質は、いつでもnullポインタを入れられてしまうことだよ
Nullableの元でもあるHaskellのMaybeモナドやScalaのOptionモナドは
無効を表現出来るが何ら脆弱と見られていない
KotlinのNullableは効率のため単なる参照型変数にコンパイルされるが
プログラム上は以下のようなコンテナと概念的には同じ
sealed class Nullable<T> {
open val isNull:Boolean get() = true
open val value:T get() = throw NullPointerException()
}
class Some<T>(override val value:T): Nullable<T>() {
override val isNull:Boolean get() = false
}
class None<T>: Nullable<T>()
>>876 自分勝手な論理展開が多くて議論にならんね。
ここはkotlinスレだし、「javaではヌルポのトラブルが多い」という事実を無視した主張はクソの役にも立たない。
「ヌルポのトラブルを避けるためにはどうしたらいいか」くらい考えたら？じゃなきゃスレ違いだからNGにするわ。
そういや、
>>870 にヌルポの観点が抜けてるな。追加すると、
・変数の初期化ミスで変数にデフォルト値(null)が入っていても、意図しない(親無しウインドウでの)呼び出しにならない。
初めてAndroidアプリ作成の案件に携わってるけどクソOSクソ端末に対応するコスト無駄すぎるな
>>895 それを判断するのは社長
現場のお前じゃない
まぁあれな感じのあれだけど、変に煽るのやめろ、誰も得しない
サーバーサイドkotlinを導入したいんだが、なんて言って上司を説得するのがいいと思う？
言語云々を論点にしてはいけない
すまん。ちょっと聞き方悪かったわ。
ライブラリが同じなのでフツーのJava経験者なら3日もあれば習得できます
>>907 クッソ頭悪いだろお前
説得する材料くれって言う要件に対してその回答はあまりにも的外れだわ
Kotlin採用していただけないのなら辞めますといえば一発や。
自分にとってどういうメリットがあるのかと
javaの仕様に追従してる層にならメリットは説明できるけど、そうじゃない層に説明するのは難しい。。
>>906 ここは一つネガキャンで。「KotlinがあるのにJavaをやるのは、JavaがあるのにCをやるようなもの。」
ただ、上司がJava至上主義者なら、「Cなんかと一緒にするな!!」と激怒するおそれあり。
そろそろ転職しようと思ってたんだがコロナの影響でエンジニアの求人は減ってるの？まだ待った方が良い？
プログラマとエンジニアは別物なので、まずその辺の違いをハッキリさせたほうがいい
でも、もしJavaならバージョンいくつ使うつもり?
Kotlinのdata classがJava14でrecordとして採用されると聞いて感動したのも束の間、まだPreviewなので正式採用はJava16辺りと知り気が遠くなった
誰もが普通にと書いたのはJava11の延長サポートが2026までだから遅い現場だとそこまで待つかなと
>>919 ラムダ式とOptionalで行けるのではと思っていた時代が、私にもありました。
ただ参照透過なプログラミングをしようとした途端、Listと配列がMutableなことが越えられない壁になる。
Java9から不変リストを作るList.of()があるけど、必要なのは実行時エラーでなくコンパイルエラーで教えてくれる不変リスト。
それを言ったらKotlinのListも不変リストではなく読み取り専用のビューなので同じなのでは
いや追加や更新機能のないリストインターフェースが欲しいということか
Windows 10 で IntelliJ IDEA を 2020.1 にアップデートしたら起動後にちゃんと動かなかった。
javaすらやったことない人におすすめのKotlinの参考書ありますでしょうか？
Kotlinは腐りきったJavaをなんとか少しでも便利に使うための車椅子のようなもの
当然、日本ユーザー会会長の太郎本！
>>930 C++, C#, Java, Swift, Rubyみたいなモダン言語の経験が無いと、Kotlinは難しいかも。
1. Clousure
2. Generics
3. Type Annotation Estimation
4. Collection
5. protocol
こう言うのが意味不明となる。
OOP自身は難しく無い。
全然関係ないんだけどさ
>>939 >3. Type Annotation Estimation
なんのこっちゃ？
>>940 最新新言語、State of Arts computer language、Advanced Language、Recent Language、Up-to-date Language
御好きにすれば！
>>946 such like Interface in Java or Abstruct Class in C++
>>948 機能的に違いないのに、名前だけ別のものつけたん？
>>940 日本人的には大正モダンでハイカラなイメージが強いけど、英単語のmodernにそんなニュアンスはないんだから直訳でモダンでもイイでしょ
アートやインテリアではモダンって普通に使うし
>>949 1. 違いない
2. 似ている
3. 同じ
これらは、全く異なる意味を持っている。
>>953 ありがとう
知らないなら普通にそう答えてくれればいいのに
>>940 ナウいヤングな君は和製英語の事は忘れて英語の modern を思い浮かべなさい。
アマゾンで検索したら7/17発売予定の本が見つかった。表紙デザインもまだ出てこない。
基礎からわかる Kotlin
富田 健二 (著)
単行本: 224ページ
出版社: シーアンドアール研究所 (2020/7/17)
言語: 日本語
ISBN-10: 4863542917
ISBN-13: 978-4863542914
発売日： 2020/7/17
アマゾンのURL書くとここに書き込みできないのでヨドバシのURL書いておく。
https://www.yodobashi.com/product/100000009003256396/ >>957 その出版社の本、本のサイズの割に字が小さくて、読みにくいんだよね。
プロトコルってなんなのかよくわからんからググったんだけどさ
プロトコルとインターフェースは呼び名が違うだけ
>>966 まじで？
>>948 は冗談で言ってるんだと思ったぜ・・・・
Interfaceって機能がなぜ必要？
>>968 具体例
図形 -> 四角形 -> 平行四辺形 -> 長方形
平行四辺形 -> 菱形
こう言うClass Hierarchyがあった時に
長方形 -> 正方形
菱形 -> 正方形
なる正方形を作りたい。
こんな時に、Diamond Problemが発生。
C++は仕様多すぎて複雑怪奇すぎて意味わからん
>>971 Golangがそれに近いのでは？
Swift, Kotlin Nativeが高速コードを吐く、万能言語を目指してるけど、今のところ達成されていない。
かといってC++が普及しているか？と言われると、初学者を撥ね付ける仕様の複雑さで、そうもなってない。
学生向けGoogleの社会貢献事業、今年のAnnouncing our Google Summer of Code 2020 students
Swiftやるみたい。
https://forums.swift.org/t/announcing-our-google-summer-of-code-2020-students/36147 複数のクラスから継承(is-a)するのは、難しすぎる・柔軟ではないので、
>>971 Rustでしょ
goはGCだからちょっと違う
>>975 なるホドォ
mix-inってのは継承チェーンに割込むって意味なのね。
気がつかなかった。
なんで、mix-inって名前なのか今、気がついた。
>>971 > C++以外の、高速で、メモリ、OSネイティブAPIを直接いじれて、アセンブリに近い言語って無いんか？
C言語
>>979 確かに。
新しいC++の仕様やSTLはとても難しいので、Cを基本として、class などの概念を使いたいなら、C++98などの古いC++の私用の範囲でやることがお勧め。
Rubyを覚えるとキチガイになるのか、Rubyがキチガイを集めるのか…
基地外がどうこうと言うより
オリジナルのルビー男を離れて模倣犯が続出したルビー荒し事件を総括して名付けられたのがスタンドアローン・コンプレックス
Rubyキチが1人なのはもちろん
このスレへの固定リンク： http://5chb.net/r/tech/1561186797/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「Kotlin 6 YouTube動画>4本 ->画像>4枚 」 を見た人も見ています：・Kotlin 5 Kotlin 2 Kotlin 3 次世代言語議論スレ[Rust Kotlin Haskell]第6世代 次世代言語15 Go Rust Swift Kotlin TypeScript "Shiritori" in English 【HP】 Pavilion Notebook PC ★11 Dart これ以上変な言語を増やすんじゃねえ！ Kotlin 次世代言語17 Go Rust Kotlin TypeScript Julia It's like you're moving in slow motion！ 次世代言語14 Go Rust Swift Kotlin TypeScript 次世代言語13 Go Rust Swift Kotlin TypeScript 次世代言語Part7[Go Rust Swift Kotlin TypeScript] English Dictionary for anime fags / Aniota no tameno eigo jiten 【IT】Kotlin 1.2正式版リリース。KotlinはJavaとJavaScriptのマルチプラットフォーム対応に Kotlin Kotlin 7 【HP】Pavilion Notebook PC ★14 次世代言語21 Go Nim Rust Swift Kotlin TypeScript 次世代言語22 Go Nim Rust Swift Kotlin TypeScript 次世代言語25 TypeScript Swift Go Kotlin Rust Nim 次世代言語28 TypeScript Swift Go Kotlin Rust Nim 次世代言語23 Go Nim Rust Swift Kotlin TypeScript 次世代言語24 Go Nim Rust Swift Kotlin TypeScript 【Library of Ruina】Project Moon 総合 Part53【Lobotomy】 【Library of Ruina】Project Moon 総合 Part38【Lobotomy】 【Library of Ruina】Project Moon 総合 Part84【Lobotomy】 【Library of Ruina】Project Moon 総合 Part42【Lobotomy】 【Library of Ruina】Project Moon 総合 Part46【Lobotomy】 【Library of Ruina】Project Moon 総合 Part62【Lobotomy】 【Library of Ruina】Project Moon 総合 Part49【Lobotomy】 【Library of Ruina】Project Moon 総合 Part7【Lobotomy Corp】 【Library of Ruina】Project Moon 総合 Part12【Lobotomy Corp】 【Library of Ruina】Project Moon 総合 Part19【Lobotomy Corp】 【Library of Ruina】Project Moon 総合 Part21【Lobotomy Corp】 IPv6 IPoE(DS-Lite)サービスのZOOT NATIVE 月額2160円から1080円に引き下げ ■ アンジュルム ■ YouTube『愛すべきべき Human Life』Promotion Edit ■ 21:00～プレミア公開 ■ Kotlin 8 (234) ZOZOTOWN pt.56 ZOZOTOWN pt.86 ZOZOTOWN pt.136 Red Hot Chili Peppers 136 【LoV】LORD of VERMILION Ⅲ【Re:3】不死スレ 96 【エムステ】アイドルマスター SideM LIVE ON ST@GE！ Part.6 Kotlin初心者質問スレ ●(07L06)2016 MotoGP R07 カタルーニャGP LIVE8● 【LIVE】東京五輪 開会式 20:00～ 【NHK】 ★26 [potato★] Red Hot Chili Peppers 120 SlipKnoT .61: The Gray Chapter 【ROM焼き】Huawei P8 lite root1 【WoT】World of Tanks Blitz Tier198 【WoT】World of Tanks Blitz Modスレ Tier4 【新生】Dorothy little happy 【ドロシー】 【WoT】World of Tanks Blitz チラシの裏 35枚目 【PS4】eFootball ウイニングイレブン 2020 LITE 至急困ってます dyld: Library not loaded エラーで 【WoT】World of Tanks Blitz 初心者スレ Tier120 【ビリーアイドル】BILLIE IDLE part2【NOT IDOL】 【SLIP有】【PILOT】パイロット万年筆71【Namiki】 雑談 The Greatest Oracle from Deep Universe of Other Intelligence. Horizon、NRK FilmpolitietでGOTY獲得 ゼルダBOTW、マリオデの存在価値とは何か Mana様がオンラインサロンを開設。「ElegantGothicLolitaAristocratVampireRomanceは不滅である」 元HKT菅本裕子 11/15､モデル務めるプリ機筐体"MOTEgenic"設置前に自撮up (*11/6､Biz系ｻｲﾄ｢東洋経済ONLINE｣にて自著連載ｺﾗﾑupも コーエーテクモ、スマホ版『モンスターファーム』が12月2日時点でのモンスター再生ランキングTOP10を発表 1位はLiSAさんの「紅蓮華」！
06:57:32 up 27 days, 17:21, 1 user, load average: 11.42, 10.41, 9.60
in 0.060398101806641 sec
@0.060398101806641@0b7 on 010820
