No.201
特段かわいくもないしカッコよくもないし、さりとてキモくもない
せめてキモカワイイくらいでないとインパクトが薄い
特段かわいくもないしカッコよくもないし、さりとてキモくもない
せめてキモカワイイくらいでないとインパクトが薄い
Kotlin 8
レス数: 289
概要: うーん、やっぱりインパクトが薄すぎるな 特段かわいくもないしカッコよくもないし、さりとてキモくもない せめてキモカワイイくらいでないとインパクトが薄い
特段かわいくもないしカッコよくもないし、さりとてキモくもない
せめてキモカワイイくらいでないとインパクトが薄い
No.202
https:
No.203
かといって if (it is MutableList<Any>) ... みたいにチェックする部分を書いても List が持つ型の Any のチェックはできないとエラーになる。
これ Java で Object のキャストする時も同じだと思うけど、List, Map, Set の類の保持する値の型に関してはチェックできないからもうどうにもならんのかな？言語仕様の問題？
No.204
その状況がまずおかしいのでは？？
No.205
No.206
何をしようとしていたかというと、まず MutableMap<String, Any> のインスタンスを作っておいて、それのキーによって値が Int だったり String だったり MutableList<String> だったり MutableList<Int> だったりするようにしたかった。
m["A"] なら Int, m["B"] なら MutableList<String>, m["C"] なら MutableList<Int> みたいな感じ。
まあ、何か他の方法がないわけじゃないんだろうけどね。(自分で専用のクラス作れば一発で解消するんだろうけどねw)。
No.207
型不明のコレクションにキャストしてから各要素をmapでキャストするかまるごと警告抑制でいいのでは
No.208
初学者が書けるとは思えないんだが。
No.209
ReactやらSwiftUIやら時代の流れで宣言的UIが主流になったからこの形式に慣れるしかないんだ
No.210
https:
No.211
もちろん、知ってる人は今までより楽なんだけどなぁ。
No.212
No.213
No.214
そろそろGradleやめてAmperにしてもいいかも
ttps://blog.jetbrains.com/amper/2024/05/amper-update-may-2024/
No.215
AWSの話もあってサーバーサイドとしても宣伝されてた
ttps://youtu.be/Ar73Axsz2YA
No.216
iOS開発環境はないからとりあえずJVMのデスクトップアプリとして動かして満足
主に書き換えたところ
build.gradleのマルチプラットフォーム化
xml→Composeに完全書き換え（これは既にほぼ移植完了してた）
SharedPreferencesをDataStoreに移行
commonMainに共通コードを移動
No.217
No.218
結構簡単そうだな。
compose重い印象あるけど、JVMの動作やリソースの食い具合は
>>216
的に満足いくレベルだった?
No.219
スムーズで満足だったよ
大量のアイテムのリスト表示もカクつくことなく、Androidで動かした場合と遜色もなくデスクトップアプリとして動いてくれた
メモリ使用量はだいたい100～150MBのリソースを食ってたから気になる人はいるかも
No.220
回答ありがとう。
アプリに寄るのは理解しているけど、ベースでのメモリの食いもそんなないんだね。
MAUIも個人的に好みじゃないし、今度作るときはCompose使ってみようかな。
No.221
参考になったサイト
Modifier.Node を使いましょう (Part 4: @Composable 関数の実装を Modifier.Node に書き換える) ttps://qiita.com/_SUR4J_/items/d48372b5793c4a0fa65f
No.222
iOSアプリ開発、Kotlinで簡単にセンサーデータを取り出せるのな、クロスプラットフォーム対応モバイルアプリは全部Kotlinでいいじゃん
No.223
io部分をkotlinxioベースに移行するプルリクがさっきコミットされた
No.224
No.225
No.226
JetBrainsに貢ぐ気のある企業だけがサーバーをJavaではなくKotlinで実装できる
言語仕様自体は何一つ文句無く素晴らしい
No.227
まあ、消えることはないんじゃない
・なんだかんだJavaの仮想マシンの上で動かせるのは大きいメリット
・AndroidがJavaファースト言語だからKotlinとは切り離せない関係にある
・マルチプラットフォーム対応
・言語仕様的にむっちゃ書きやすい
・ビルドツールのGradleが便利
ただしJetBrainsはクソ、金の亡者
No.228
No.229
No.230
No.231
Mac miniとiPhone SEを買うと15万円くらいかかる
androidだとWindowsはあるので、手持ちのandroidスマホはテスト機に使わないとして、Galaxy aだけの2万円で済む…
No.232
WASMだからiOSだろうとデスクトップだろうとブラウザで動くから便利
No.233
9/18/2024
・Language evolution: more efficient data handling, increased abstraction, and enhanced performance with clear code.
・K2-based IntelliJ IDEA plugin: faster code completion, improved highlighting and search, and more stable code analysis.
・Kotlin Multiplatform: release direct Kotlin to Swift Export, streamlined build setup, and simplified creation of KMP libraries.
・Experience of third-party ecosystem authors: simplify development and publication process for Kotlin libraries, tools, and frameworks.
For more details, head over to our Kotlin roadmap page. Explore our accomplishments and learn about our key objectives and future plans!
https:
No.234
No.235
・省略記法を推奨してること
関数引数の()を省略okにしないで欲しい
・引数最後のラムダを()の外に出して良いとか言わないで欲しい
・
No.236
No.237
No.238
rubyからgroovyを経由してKotlinに取り込まれたDSL作成能力の要の記法なので、無くすわけにはいかない
No.239
ラムダを出していいのは、そういう関数を作りやすくなるから流石にほしい。
No.240
じゃあそういう自分が気に入る記述の言語を作れば？
自分で作らなくても仕様公開しておけばそのうち誰かが作ってくれると思うよ。
No.241
No.242
ラムダ引数の外出しが嫌ってのはわからん
なんでもきっちりしてないと嫌なタイプかね
No.243
fun interface MyInvoker {
operator fun invoke(input: String)
}
val invoker: MyInvoker = MyInvoker { input ->
println(input)
}
これと同等
val invoker: MyInvoker = object : MyInvoker {
override operator fun invoke(input: String){
println(input)
}
}
No.244
kotlin でVBA みたいな記法見てげんなりしたんよ
No.245
しいて言うならばKotlinのほうが記法の自由度が高いと思うけどそれが気に入らないのか？
No.246
C# -> F# の変貌っぷりよりはよっぽどマシ
No.247
No.248
F#やScalaは関数型を目指した言語だけど、Kotlinは普通のOOP言語なので
No.249
F#やScalaは関数型を目指した言語だけど、Kotlinは普通のOOP言語なので
No.250
VBAはよくない→似た記法がある→Kotlinにも悪感情
これ、何の合理性もない偏見であることに気付こうぜ
VBAやVBに問題があるのはカッコが省略可能だったり書き方の自由度があるからではない
自分で信者と言っているあたりある程度自覚と自虐があるんだろうけど、こういうお気持ち優先のコメントに振り回されるのはやめたい
