Kotlin [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
JetBrainsが開発した期待の新言語Kotlinについて語りましょう
https://kotlinlang.org 関数の戻り値の型ならnullable欲しいな
戻り値がnullになるとき毎回exceptionをthrowするのかって話 例えば数値を文字列として格納してるデータをファイルとかDBとかから取り出すとき
その値は数値としてしか使わないけどもしかしたらnullな場合もある
getter関数作るのにgetterでは必ず文字列として取得して変換可能か判断してから数値にする処理を毎回するか変換できなかったらcatchするのか
そんな場合なnullableがあれば外からみた関数の使い方はシンプルにできる だからnullオブジェクトを用意して使えって。
型安全でないnullなんか窓から投げ捨てろ。 入力欄のオプショナルな項目か
携帯電話を持っていれば、その番号を記入して、みたいな奴か >>196
同じようなことを考えたことがあったけど、「実行時エラーは悪」という考えにとらわれると、
間違った値(デフォルト値)のままエラー無しに処理が進んでしまうのは実行時エラーよりたちが悪い
ということを忘れがちになる。
>>197
使用頻度を考えるとnullオブジェクトをいちいち定義するよりnullチェックのほうがましな
変数の方が多いと思われる。
また、nullオブジェクトはどんな状況で使われても適切な結果を返すように実装しなければ、
上で述べたデフォルト値の問題を起こすことになるから、ミスのないデフォルトを
設定すること自体が難しい場合もあると思う(使用経験が少ないからわからない)。 >>205
今時はなるべく完全コンストラクタを使って最初に一括で初期化し、
後は一切変更できないクラス設計が好まれるんだよ
C#は見境なく大量のgetsetプロパティを持つクラスを定義するバカが多いけど nullチェックはもうちょっと痒いところまで手が届くといいね
たとえば if(a == 0 && b?. == "hoge") {...} で2つめはnullならパスしてくれる
みたいに書けたら便利 >>205
コンパイルエラーにできるものを実行時に処理するのは良くない設計だな。
型無しのnullを使うとコンパイルエラーに出来なくなる。
nullオブジェクトでも実行時エラーは処理できるから、必要ならそうすりゃいいし。 >>209 と、いわれても既存APIにはnullableだらけだからなぁ そのAPIの中はそれで良いと思う
今後作るAPIについては別に過去をなぞる必要はないとも思うよ Kotlin/NativeをAndroid(NDK)で動かしたい >>210
およそ
nullがコンパイルエラーになる > 適切に設計されたnullオブジェクト >
nullチェック > 実行時NPE > 不適切なnullオブジェクトでエラー無しに誤った処理が進む
という順位なので>>210とは特にそれほど見解の相違はないと思う。
nullオブジェクトは必ず容易かつ適切に設計できることを暗黙の前提とするかどうかが相違点かな。 tensorflowをサポートするらしいけど、どうせならpython自体を扱えるのを目指してくれたらいいのに ハマったので備忘録程度に。
Kotlin/JSで@JsNameの使いどころは、公式ドキュメントでは
In some cases (for example, to support overloads),
となっているが、引数ありのトップレベル関数はoverloadしていなくても
@JsNameをつけないとトランスパイル後の名前が変えられる模様。 >>217
目指すの意味がさっぱり分からんけど、kotlinじゃなくjython使うのじゃダメなの? >>219
たぶん>>217はCPythonのライブラリをKotlinから使いたいのであって、
JavaやKotlinで書かれたものをPythonで呼び出したいのではないと思う。
JythonはPython3に対応するめどもなさそうだし.... そうそう、kotlinから直接pythonライブラリ使えたらいいなー、と。それだけ。
JetBrainsならやってくれそうなんじゃないかとw
jython、そうなんだよ、開発止まってない? > CPythonのライブラリをKotlinから使いたい
JythonでPythonコード(CPythonのライブラリ)をJVM上に読み込んで
KotlinでJVM上に展開されたバイトコードを呼び出せば良いんでないの
という意味だったんだけど、そうじゃないんだろうかねぇ
他の在り様を考えたけど、どれも現実的でない構成になってやっぱり分からん
案1. KotlinコンパイラがPythonコードをコンパイルできるようにする => それJythonじゃん...
案2. JNIのサポート言語(C/C++)にPythonを新たに追加する => Oracleに言えよ...
案3. JVM, CPythonプロセス間をWSGI的なもので繋ぐ => もう何が何やら...
まぁ深く考えないで、素直にKotlinからtensorflowのJava APIを叩くのが一番楽だと思います >>223がどの程度Pythonに詳しいかわからないけど、PythonのライブラリはPythonだけでなく
C言語などを混ぜて書かれていることも多いので、
> Pythonコード(CPythonのライブラリ)をJVM上に読み込んで
ということ自体ができないと思う(自分もそこまで詳しくないから確証はない)。
Pythonで書かれているライブラリでもPython3に移行しているので、Python2ベースのJythonには
使えないし。
あと>>223はJVM前提みたいだけど>>221はKotlin/NativeみたいにJVMから離れて
CPythonのインタプリタ上で(あるいはCPythonのAPIを呼び出しながら)Kotlinを実行する
ことを想定しているからかみあわないんだと思う。
> 素直にKotlinからtensorflowのJava APIを叩くのが一番楽だと思います
tensorflowはその通りだけど、>>217はそれ以外のScipyみたいなライブラリのことを
言っているんだと推測。 >>221はKotlinコンパイラでPythonコードをコンパイルしたいって言ってるから一旦理解したが
>>224はCPythonコンパイラでKotlinコードをコンパイルしたいって言ってて草生える
別の人間の意見だからそれは良いんだけど、どっちにせよ馬鹿っぽい構成だな
Kotlin/NativeでJVMから離れても、
結局はKotlinランタイム, Pythonランタイムの2つの言語/プロセス間通信が必要で
他言語間通信はC言語を挟めというのがイマドキの現実的なI/F設計だろうに
そのC言語I/FにKotlin, Pythonのラッパーを噛ませるならギリギリ現実的か
Python2が3に移行してるって言うが、Googleが10年以上Python2に固執したせいで
ようやく最近Python2, 3が平行実装になった程度で完全移行は進んでないだろ...
Jythonなんかはその煽りで3への移行をやらず枯れきった性質だと思うぞ >>224 普通に空気読んでくれてありがとねー笑
>>225 現実に今すぐ俺がkotlinでPythonライブラリ使いたいと言ってるわけじゃないんで、見当違いだが詳しい解説ありがとねー
JBはiOSにもネイティブでkotlinを対応させようとしてるくらいだし
方向性としてすべての分野でkotlinを使えるようしようとの野心をもってるらしいし
もとものkotlinは産業用に開発してると謳ってるわけだけど
tensorflowに対応させるなんて発表聞けば、研究分野、この場合機械学習だけども、にも
ターゲットを広げたんかな、と
ならばいっそのことpythonライブラリ全般を使えるような開発をやってくれたら
さらにいろいろ広がるんじゃないか、とそういう期待
PyCharmとか出してるくらいだし
まぁ人的資源とかの関係もあるだろうから優先順位低いだろうけどね
googleだってもしかしてJVMと決別を視野に入れてkotlin/nativeを評価したのかもしらんし? 現にFuture plansには入ってるんだよね、Data analysis and Scientific Computingが
どうやって実現する予定なのかはわからんけど それとも何か?この科学技術計算ターゲットってのは
もしかしてイチからkotlinで科学技術計算ライブラリ
もしくはコミュニティまで作ろうってことなのか?
まさかtensorflowに対応で完結じゃあるまい?w
いずれにせよJBが近い将来どんな具体策を出してくるのか、非常に楽しみである JVMもPythonも知らない素人だった
相手した二人共これには苦笑い kotlin見てみたけどこれscalaをオチンポ向けにした言語やな 全然知らないで書くけど
Javaと同等の事をKotlinで出来るの? できるんでないかな
Javaの呼び出しもシームレスにできるしな Kotlin = Scala + Groovy(Rubyも同じ)
Javaでは、nullを除去できない
Javaには、Primitive があるけど、
Kotlinでは、すべてがオブジェクト
Java ←変換可能→ Kotlin
クロージャのデフォルト引数は、it を使う
第2引数のラムダ式を、引数の外に出せる、糖衣構文あり
関数(引数, { it })
関数(引数){ it }
toString, equals, hashCode の3種の神器を、最初から持っている、データクラスがある >Javaには、Primitive があるけど、
>Kotlinでは、すべてがオブジェクト
実行速度を上げるため、primitiveを使う方法もある 途中からJavaとの違いからKotlinの特徴になっててイマイチ、、、
とりあえず、Javaとおなじこと出来るでいいんでね 初歩的な質問とかしていい?
ByteArray使いたいときって
val a = byteArrayOf(0x80.toByte(), 0xCA.toByte(), ...)
みたいに.toByte()ってつけなきゃいけないん?慣れるまで見づらいな… いろいろ考え方はあるのだと思うけども
なにかコレクションがあって、それ全てに何か処理をして返して欲しいときはmapが使える
>>> val array = arrayOf("aaa","bbb","ccc").map{ it.toUpperCase() }
>>> array
[AAA, BBB, CCC] >>238
Kotlinは通常キャストはされないが、byteはリテラルがないからかリテラルだけは型推論されて、
val bytes = byteArrayOf(0x01, 0x02)
というのは型検査を通る模様。 kotlinでjsってどんな感じ?
typescriptの型情報取り込めると知って
ちょっと気になってきた。
type scriptより関数型が強めだから幸せになれそう SwiftとKotlinでちょっと遅延評価リストを比較した
■Kotlin
オンラインコンパイラ: https://try.kotlinlang.org/
val a = generateSequence(0){it+1}
//A 問題なし
println("A: "+ a.take(10).toList() )
//B 問題なし
println("B: "+ a.take(10).map{it*10}.toList() )
//C 問題なし
println("C: "+ a.filter{3<it}.take(10).toList() )
//D 問題なし
println("D: "+ a.map{it*10}.take(10).toList() )
//E 問題なし
println("E: "+ a.map{it*10}.filter{50<it}.take(5).toList() ) ファイルの整形処理で少しカジッてみたけど、ファイルIOはJavaのAPIと古い?関数と新しい?関数が混在してて、Googleの海をさ迷ったよw
kotlinのsequenceを返すreadLinesが欲しかったんだけど、見つけきれなかったので自作した。
既存であるのかな? lineSequence()とかuseLines()とか? androidアプリってscriptの方で作れますか?
kotlinc -script ヘイ親方質問
ファイルをShift_JISで保存してもUTF-8で保存しても
fun main(args: Array<String>){
println("日本語です")
}
が特段のオプションなしのkotlincでコンパイル可能で
特段のオプションなしkotlinでWindowsコマンドプロンプトに無事表示可能なんだけども
これはいったいどのへんが気を遣ってくれてるんですかね >>144-150
自己レス。データクラスを使った
data 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 )
}
出力
Person(age=20, name=Alice)
Person(age=20, name=Kate)
Person(age=25, name=Dave)
Person(age=25, name=Tom) C#やってる人にとって凄く扱いやすかったりする?
ちなみに母ちゃんのあだ名がコトリン 秋の奈良レンタサイクル“古都りん” - 奈良県自転車利用総合案内サイト
nara-cycling.com/rent-a-cycle/ >>247
kotlinじゃなくてJavaの仕様でしょ。 なんでgoogleはkotlinをアンドロイドアプリの公式言語にしたの?
なんでgolangじゃないの?
オラクルとの訴訟もあるのにjavaを切ったほうがいいんじゃないの? >>254
オラクルとの訴訟での争点は言語じゃなくてAPI
言語を何にしようが無関係 >>254
使ってみればわかるけどgolangってメタプログラミングな部分が弱いから
既存のシステムの置き換えに向いてる言語ではないと思う。
新たに1から構築するなら可能性はあるけど。 >>256
これ。でも段階的にjavaに頼らないようにしていくのかもね。
コレクション系がandroid用に別実装になるとかあれは面白い。
あとオラクルにjavaから離れるアピールして圧力をかける政治的意図もあると思う むしろ、なんで買収しないんだろな。
つーかjetbrainが謎すぎて。
なんで一社であんなに幅広くide作れるのかが謎 共通のベースに言語乗せてるだけだし、開発なんかほとんどオフショアだろ Kotlin nativeも頑張ってるしな。
結構そっちにも期待。 >>265
これが本格的に動き始めたらswiftの存在意義が、、、、、無くなるよね ラットナーがjetbrainsに転職するってマジ? Swift on Androidが地味に進んでるからそっちも期待
一定量の完成度が見込めたらKotlinから移行するのも良いかも >>270
地味に進んでるって、Xamarin Androidのように、SwiftからJavaのAndroid APIを呼び出す仕組みが用意されつつあるの?
それが出来なきゃKotlinの代わりにはならんよ kotlin/nativeでndkを使いたい
sdk側とndk側で同じ言語使えたら開発楽だと思う Kotlin.NativeからObjCが叩けるようになるのが先か
SwiftからJavaが叩けるようになるのが先か
どっちも現実的にはないわな
まぁそれでも言語/フレームワークの開発が絶賛進行中のSwiftの方に夢があるかな >>275
その用途だとKotlin nativeじゃ多分意味無い
Nativeコードに変換すればc++で書いたのと同じ性能が出るというわけじゃないからね いやJVMは十分速いよ?
C++でもJavaと同じように書いたらパフォーマンスは大差ない
C++が速くなるのは低レベルな汚いハックができるからで、それができないならあまり意味がないということだろ >>277
kotlinから変換されたllvmコードは、kotlinの言語仕様を満たすために、
例えばメモリ管理はガベージコレクションが前提となるから
その為の少し大きめなランタイム付いてくるはず
境界チェックのようなc++なら省略できるコードも漏れなく付いてくるはず >>276
c++ほどの速度は出ないのね
結構早くなると思って期待したんだけど
>>278
以前画像にブラー処理掛けたときは結構違った それは言語の違いではなくアルゴリズムの違いではなかろうか
もしくはJavaヒープ/Nativeヒープの性能差分ならByteBufferを使う手もある
そこまで考慮するくらいなら素直にC/C++使った方が幸せだけど
ByteBufferはGC走りづらいから性能良いんだけど普通は使わないよねぇ ByteBuffer(もしくはそれと同様の使い方をするプリミティブ配列)がGCの性能に大きな影響を与えるって一体どんな状況?
バッファは長時間使い回すんだからGCなんかほとんど関係ないだろ
GCの負担になるほど頻繁に生成しまくるとかアホなことしてるとしても、その場合はネイティブヒープの方が割当時のオーバーヘッドの分かえって遅くなりそうだし メモリ管理とかよりさ
JVMやDEXの中間コードからJITされたコードの場合、SIMDとかの特殊なCPU命令はまず使ってくれない
つまり十分に最適化されたネイティブコードに勝てる見込みはまずない
最適化されたライブラリの一つであるlibjpeg-turboみたいなのをアプリから使うときに
libjpeg-turboのAPIを一つ一つJNIでラップするのと
libjpeg-turboのAPIをNDKで利用してからアプリ固有のAPIだけJNIでラップするのと
どっちがリソース管理が楽かは言うまでもない
この「NDKで利用して」をKotlin Native でより安全に書けるのなら、価値はありそうだな んなこたない。
JITでSIMDぐらい普通に使われるし、
むしろ事前に最低限サポートするCPUを決めてそれに足を引っ張られる事前コンパイルより、実行しているCPUの拡張命令を最大限使えるJITの方が効率的なコードになる事もある。 Dalvik, ARTどころかOracle JVMですらSIMDは扱うよ
>>282
俺が使った時は、Androidでnew byte[1024]がOutOfMemoryでByteBuffer.allocate(1024)は通るような状況(実際は1KじゃなくM単位
画像加工を試みたんだけどbyte配列のままで処理しようとしたら分割操作が必要になってクッソ重たいのwww ByteBufferのAPI嫌いだな
Javaの過剰設計の伝統ここに極まれりって感じ NIOが出た当初も評判良くはなかったよねー, ないと困ることは確かにあるんだけど必要とする人は少ないし
それでも当時は仮想マシンを謳うくせにこんな基本機能もないのかよって風聞で過剰どころか不足と言われ
1.4は標準ライブラリを大量に追加しようってリリースだったから仕方ない ByteBufferはdirectがあるからまぁ必要。 間接的にお世話になってることも知らずに文句言ってるアホばっか。 エンジン構造も知らずに車に文句付けてるってくらい論点が異なるよ
使う側であれば別に中身を意識しなくていいんだよ >>288とかはエンジンなんて車にいらねーって言ってるんだけどなw APIに文句言ってるだけじゃね
Javaが使いにくいからとKotlin使ってるお前らにそれを批判する資格はない 実際問題java apiからkotlinを切り離すのはわりと簡単だったりするの?
google内で独自apiを作ってたりして ■ このスレッドは過去ログ倉庫に格納されています