Kotlin 6
■ このスレッドは過去ログ倉庫に格納されています
JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう
※前スレ
Kotlin 5
https://mevius.5ch.net/test/read.cgi/tech/1544268581/ >>455
何を使うにしても状況に適したものを使えば問題ないと思うよ >>450
NullObjectはどのような場合でも正しく機能するNullObjectを定義できるなら優れているが、「どのような場合でも」を満たすのは難しい。
null発生の状況が複数ある場合は「どのような場合でも」というい条件を満たすNullObjectが定義可能である保証もない。
最初は条件を満たしていても、プログラムを修正していくうちに条件を満たせない場合が出てくる可能性もある。
しかも「気づかないうちに」そうなっている可能性がありたちが悪い。
条件を満たせない場所だけ分岐させるのは、NullObjectがnullチェック分岐消去を目的にしている
ことを考えると本末転倒な解決策。 APIレスポンスとかデータ定義はNULLじゃない扱いしておいてビルドエラーもでないけど、
実際に動作させるとNULLが来てクラッシュするとかあるな すごーく簡略化すれば、
private hoge: Hoge? = null
public Hoge apiX() {
if (hoge == null) hoge = Hoge() //
return hoge!! // ここでnullはあり得ないよと「宣言」
}
実際にHoge()のところは、さらにJavaの他のAPI呼び出しだったりするとしても、
とにかくnullでないことさえはっきりしているならばなんでもいい。
要するにこの場合は、apiXがnullを消費する責任を持つってことだ。
持たないなら、nullableのまま返す(つまりAPIとしてはnullも正常系だと言っている)。
そんだけのことじゃないかな。 >>459
nullobjectは「賢いnull」なんだから、null的な使い方してもいいだろ。
型安全なnullとして受け取ってnull分岐してもいいしな。
あと、null発生の状況が複数あるなら、それぞれ別のnullobjectにしていいんじゃない?。 Javaではnullobjectを賢いnullとするのは正しいと思う
でもnull許容/非許容を型で区別出来るようになったKotlinでは
nullobjectはその利点を無くしてしまう
実装持ちobjectとnullobjectを区別する必要が無い場合は何も問題無いけど
もし「nullobjectかどうか」を判定する必要がある場合は
賢いどころか逆になると思う NullObjectは"Tell, Don't Ask"なクラス設計ではうまく機能するんだけど、
関数型チックになAskだらけのコードだと使い物にならんね >もし「nullobjectかどうか」を判定する必要がある場合は
これはないだろ。動機そのものだから。 >>465
それなら良いけど、ケースによらずnullの代わりに使うみたいな話の流れだったから
ログインユーザーとかも無効ユーザーオブジェクトになるのかなと nullの場合の動作を
呼び出す側が決めるのか呼び出される側が決めるのか
どちらが適切なのかを考えるといい
呼び出される側が100%決め打ちできるユースケースならNullObjectは有効
呼び出し側でハンドリングしたくなったら邪魔 java脳からkotlin脳へアプデが必要だけど
私の脳はnull 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って非同期呼び出しとかどうすんの
OOの原理主義的にはコールバックの呼び出しもしないのが正しいんだろうけど、
最近は前後で文脈が繋がってて、コールバックが呼ばれないままだとまともに動かないケースがほとんどだよね
かといってコールバックしようにも引数に何渡せばいいのかとか色々無理がある >>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 native試したことないけどこれ糞過ぎやろ
既存の(JVM向けに書かれた)コードがほぼ例外なく実行時にクラッシュすることになるやんけ
こんな互換性の欠片もないもん作るんやったらもう別言語でええやろ kotlinてクラス変数に型推論使えるの?
Javaで無名クラスに利用できたらいいのにと思ったことがある
class Hello {
public var xyz = new Object (){ int x; int y; int z; };
void setX(int value){ xyz.x = value; }
} >>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でクロスプラットフォーム狙うならリッチな標準クラスライブラリがないと駄目だろ。言語だけ用意されても。
kotlin/JVMみたく他に寄生するなら寄生先のライブラリ使えるからいいけど。
nativeどうする気なの。
.netやjavaみたいな最低限の標準クラスライブラリないと役立たず。 どうする気もないでしょ
JBが本気でKotlinで天下獲るつもりならGoLandとRiderとResharperを今すぐ廃止すればいい
それをしていないということはその程度の覚悟なんだよ
粛々とチームを解散して開発者を解雇するだけだ クロスプラットフォームがこんなに早く普及し始めるとはのぉ。 JavaでWindowsで開発してlinuxでうごかしとる
バージョンはこないだまで6だった
やっとJavaのかかとの所ぐらいまで世界が追い付いてきたようだ Kotlin/Nativeってバージョン番号が1.0を越えてるけど、
ベータ版を脱したってことでいいの? クラスのnullableなインスタンスプロパティが複数(a,b,c)あって、
それらが全部nullじゃないときに実行できるメソッドあり、
fun execute() {
if (!canExecute)
return
val a_ = a!!
val b_ = b!!
val c_ = c!!
}
いちいちこういう事やってんだけど、なんとかならんもんか・・ 小手先のテクニックよりも設計を見直すべきでは
a, b, cを一つの型に纏められないの? MVVMのViewModelつくったことないの?
ViewModelを作るとたいがいこんなことになるんだが。 >>498
いや、なんでa, b, cをわざわざ別個の変数に代入し直す必要があるの?
そこMVVM云々の事情は無関係だよね
HogeModel(a!!, b!!, c!!).execute()とかなら別に違和感ないやろ 普通のクラスだとこんなことにならんが、複雑に状態が遷移するViewModelだとこんなことになる。
ちょっと前にNullオブジェクトパターンの話題あったけど、NullオブジェクトじゃなくてViewModelの内部でStateパターン使えばたぶんいけると思うがめんどくさそう。 >>499
ああ、!!排除するために内部でそのために別のクラスに追い出せってことかなるほど。 つか、そのためだけならクラスを別に用意するんじゃなくてもいいんだよな。
ただ、executeCoreって別のnon-nullableな引数とるメソッド用意してexecuteCore(a!!,b!!,c!!)するだけで
実際のその先の処理もa_.hoge(b_,c_)とかでちゃんと処理委譲してるから毎回10数行レベルで、更に他に分割するって発想なかったわ。 nullチェックのガード節後に、スマートキャストが効けばいいわけだな みなさん
今日からKotlinを目指す事になった者です
よろしくお願いします >>509
え?
Kotlinって言語の事じゃなかったんですか!?
てっきり言語かと やっぱりプログラミング言語で合ってるじゃないですか
初心者をいじめないで下さいよ kotlin始めましたならわかる
kotlin目指したらhallo world書いたら目標到達じゃないか >>513
でもまだ本が届いてないんです!
かといってプロゲートを調べたらKotlinがないしドットインストールを調べたらクッソ高ぇし
ヨ■■■で
作って楽しむプログラミング Androidアプリ超入門―Android Studio3.3 & Kotlin1.3で学ぶはじめてのスマホアプリ作成
って本をポチりました >>513
こんな状態で僕はKotlinを始めている事になるのでしょうか!? >>516
なってるよ
だからもう書き込まないでね >>514
そんなこと書いた張り紙がラーメン屋にさりげなく貼られてたらどうしよう >>509
すいませんでした
調べたらKotlinの源がJavaという事が判明しました
NGIDを解除しました
ですから今はまずプロゲートでJavaをやってます オンライン講座やアプリにカネをかけたら負けだと思っているのでJavaの本もポチりました
「Java1年生―体験してわかる!会話でまなべる!プログラミングのしくみ」
まずはこれを読んでから
「作って楽しむプログラミング Androidアプリ超入門―Android Studio3.3 & Kotlin1.3で学ぶはじめてのスマホアプリ作成」
を読む事にしました
アデュー 各言語のスッキリシリーズを生み出した、伝説の本!
まずこの本で、オブジェクト指向を学ぶ。
スッキリわかる Java入門 第2版、2014
その後に、太郎本をやるのが定番!
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016 >>515
たぶん開発環境があってないから楽しめないと思う
サンプル系の本は苦しみながら修正して作るものだと覚悟して望んでください
そうすればとてもいい本です >>522
そういや動画はわかりやすいと誰かが書いてたな。俺はわざわざ動画探して見ないけど。 手動かしてたら覚える
本も動画もメンターもいらなかった 勉強してプログラミングを覚えてからアプリを作るっていう考えがそもそも間違い
まず作りたいものがあるべきでその作りたいものを作るために必要な知識を
都度調べて問題の解決を繰り返すという方法で進むべき
作りたいものがないなら向いてないからプログラミングなんかやめてしまえ時間の無駄 まあ、そう言わんでも
君が数学を学んでいた頃、数学でやりたかったことあったの? 回転機能とワイヤーフレーム3Dでドヤってたら
あっという間に世間はポリゴンだのテクスチャだのバンプマッピングだの
ほんの数年の間の話 大体アプリを作るのに必要な知識って言語の文法だけじゃない
Android SDKの知識も必要だし設計もMVVMとかfluxとかいろいろある
今の主流の外部ライブラリが何かとか非同期処理の実装はどうするか
Firebaseとかも活用した方がいいだろう
必要な知識が広すぎるのに目的もなくただ漠然と必要そうだとつまみ食いしてるだけで
あっという間に時間は終わっていく
大体5年もすればソフトウェアの世界は一変する
結局何も生み出せないまま技術に振り回されて時間が過ぎていくだけ さっき気がついたんだけど
kotlinってimportしなくなった?不要なの?
Math.sin/cos/tan使ってもimportせずに使えてなんか変な感じです 1.4でkotlin/nativeが爆速になってgoが死亡する世界線に行きたい 誰かが1000億円の間違いしなかった世界がいい
今更Kotlinとか付け焼刃 >>528
その通り。
まあしかしそれ言ったら学校教育は完全にダメだね。 >>533
俺は変な感じがしない。なぜならJavaの頃からそのように使っているからだ。というかむしろそうでない方に違和感がある。 >>538
本人ではないが>>536はJavaに最初からnulll(=1000億円の間違い)がなかった世界線に行きたいらしい。 union って、C言語の union のこと? そういうのはないね。自分で無理矢理 Byte 配列に詰め込むのなら出来るが。 こういうやつでしょ
var a : (String | List<Int>) = "aaa"
a = listOf(10)
無いよ 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と同じくオブジェクト宣言にすれば型としても値としても使える
TypeScriptのようにリテラル型という方式もあるけど
function f(): string | null | 10 { return 10; } sealed classってinterfaceを持たないfinalなクラスをEither型には出来ないってことであってる? あけましておめでとうございます。
ことりんもよろしくおねがいします。 ■ このスレッドは過去ログ倉庫に格納されています