Kotlin [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
JetBrainsが開発した期待の新言語Kotlinについて語りましょう https://kotlinlang.org 画面はWebView(JavaScript連携)でいいよ そこそこの長さの文字列をわかりよく文字列のリストにする方法ってないですか "ABCDE".toList()だとCharのリストになってmapとか繋げて変換がいります "ABCDE".split("")だとなんか7つのリストになります 文字境界の正規表現を指定すればいいような気もしますが探せませんでした >>643 "ABCDE".split("(?=.)") ではどうか? >>> "ABCDE".split("") [, A, B, C, D, E, ] >>> "ABCDE".split("").size 7 >>> "ABCDE".split(Regex("(?=.)")) [A, B, C, D, E] おお、ありがとうです しかしありそうでないのねStringで分けるやつ 👀 Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) >>645 "ABCDE".map { it.toString() } これおすすめ だからそれだとStringをCharにしてからStringにするという手間がかかっ for(int var6 = 0; var6 < var5.length(); ++var6) { char item$iv$iv = var5.charAt(var6); String var13 = String.valueOf(item$iv$iv); destination$iv$iv.add(var13); } …ってなかった。最近の言語のコレクションのmapとかあのへんのメソッドは空気を読んでて困る(えらい)。じゃあこれにします Kotlinは配列というかリストになんか入れるとエラーで二度と引き出せなくなるのが嫌 何か不都合があって引き出せないのなら最初から弾いてくれ あのへんは型とか継承とかの理解きちんとしてないとちょっと複雑なの入れたときものっそいエラーになるよ 適当に書いて適当に使ってると動くと見せかけていざというとき詰まる箇所ベスト3に入ると思う 具体例があると話も広がりそうだけどイメージがわかない コレクションって色々種類があって、 問題によって適切なクラスを選ぶべきとか言っていたくせに mutableListはmutableListしか種類ないし、それで別に問題がないってどういうことだよ フィールドもprivateにしてsetter, getterからアクセスしろとか言っていたくせに プロパティアクセスは実質フィールドをpublicにしているのと変わりないじゃねえか その他、継承は良いことだからたくさん使って活用していこうとか言っていたくせに openをつけないと継承できなくして、実質継承は推奨しないみたいになってるのなんなん 嘘ばっかり言いやがって >>652 「のっそい」って何処の方言?沢山って意味? >>654 いろいろ勘違いしててどこから突っ込めばいいのやら プロパティアクセスは、publicなフィールドへのアクセスと違って、 setを制限してgetだけにできるし、 setするときの値チェックなんかもできるし、 privateフィールドをsetter/getterでアクセスする利点はそのままに、 使うときの表記をシンプルにしてくれる 継承するよりコンポジションしてアクセスを転送する方がいいっていうのは もうオブジェクト指向では定説 ミュータブルなコレクションに厳密な静的型チェックを適用としようとするのはいろいろ限界がある Javaでは厳密な静的型チェックを放棄して使いやすさを優先してる 今更だけど、StringをStringリスト(配列)にするってクッソ馬鹿っぽいな Stringをnewするのも重いし、確保したメモリをGCで回収するのも重くなる 「StringをCharにしてからStringにするという手間」とか言うならChar配列で扱えというね String配列扱うくらいに性能を考えないなら、当初の通りに#toList #map使っててもおkだろ >>654 >mutableListはmutableListしか種類ない 意味がわからない 大枠でList, Set, MapなどがあってLinkedHashMapとSortedMapは順序制御が違うし ArrayListとLinkedListは追加削除のパターンによって計算量オーダーが異なる >setter, getterからアクセスしろとか言っていたくせに 構文が理由ではない >フィールドをpublicにしているのと変わりない 構文が変わりないだけ >>660 Stringがイミュータブルなら、 Stringの一部分を取り出して新しいStringを作るのはとても軽い処理でできる その新しStringを作る仕組みで配列を作れば、それも軽い COW信者乙 さておき、入れ物のStringインスタンスをnewするのはやめたいよな 中身をコピーするかどうか以前にJVM上のインスタンスの確保が重たいんだよ そして、GCで回収して回る対象個数が増えて重たくなるのは中身のコピー有無は関係ないんだよ かといって日頃パフォーマンスに影響するような膨大な処理をさせてないので気にならない 気に入らないところが、JavaやScalaを使い込んだ人視点で、このスレレベルからみるとむしろズレてるね >>662 そういったイミュータブルな文字列を表現するデータ構造として Rope がある ・Rope (data structure) - Wikipedia https://en.wikipedia.org/wiki/Rope_ (data_structure) ・ロープ: 理論と実践 - IBM developerWorks / Java technology https://www.ibm.com/developerworks/jp/java/library/j-ropes/ ・最終報告 - Ropeを用いたRuby処理系の高速化に関する報告 http://www.spinute.org/ruby/gsoc2016/japanese.html 特に「Stringの一部分を取り出して新しいStringを作る」という substring 操作に関しては、上記の Wikipedia のページからリンクされている 原論文(英語)の中で疑似コードを使って丁寧に解説されている で、肝心の Kotlin 実装は知らない(汗 >>641 tornadoFXのマニュアル今読んでいるところだけど、tornadoFXだめなのか... >>642 前やってみたけど、Javascriptとつなぎ合わせるところが、ちょっと面倒だった。 型安全でもないし... >>666 文法が気に入らないって言ってるだけでJavaやScalaを使い込んでるようにも見えんがな JVMの仕様上、JavaやScalaの方が最適化されてるからKotlinが気に入らないって話かと思って読んだらもっと浅い話だった Kotlinの文法が良いってこのスレは賞賛してるから論点はこのスレと合致してる ただ、Kotlinの文法がダメって記事と、Kotlinの文法がイイってスレとで感想が真逆なだけだ tornadoFXはDSLのダメなとこ出てるねえってだけだから、それ気にならないならいいんじゃないかな 足りない情報は君が発信するんだ Kotlin は、Groovy, Scala, Ruby の影響を受けている Ruby を関数型にした、Elixir を意識している。 関数型では、デフォルトが、immutable ねえねえおにいちゃん ミュータブルリストの先頭から要素を削除して詰める(戻り値不問)って行為をいちばんうまくできる書き方ってなあに コマンドラインでこんな風にできたが >>> val a = mutableListOf(1, 2, 3) >>> a [1, 2, 3] >>> a.removeAt(0) 1 >>> a [2, 3] kotolinってc#で言うpartial classみたいなことできないのかな? 実装を分けたい fun main(args : Array<String>){ test(){ println("test!") } } fun <T> test(body: () -> T ) : T { println("START") try{ return body } finally{ println("END") } } これで (returnの行): error: type mismatch: inferred type is () -> T but T was expected ってエラー出るのなんでですか まだどっかに<T>って書かないとダメですか STARTって表示してtest!って表示してENDって表示するようにしたいんですが bodyは () -> T じゃん?つまり body() がTじゃん? 返り値いらないならUnit型でも コピペ参考でジェネリクス書いちゃう気持ちはわかる ネットとかにある高階関数なんかのサンプルはたいていなんか小難しいパターンやってるからな ちょこちょこ検索してみたけどシンプルなのはなかなかないようだ というわけで顧客が必要だったもの: fun main(args : Array<String>){ test(){ println("test!") } } fun test(body: () -> Unit){ println("START") try{ return body() } finally{ println("END") } } 超わかりやすい >>680 それ return 書かなくても同じだよね? 簡素化のためにUnitを返す型をクロージャーにしてるけど任意の型を戻せるようにしたいんじゃないの >>680 は顧客が本当に必要だったものとは別のものが出来上がってる事例な気がする >>677 return body ではなく return body() では? 前から思ってたんだけど、Kotlinって val hogeIsEmpty = hogeが空かどうかのわりと長い1行 if (hogeIsEmpty) { // then } みたいな読み下す優先の変数の名前とか分離定義って推奨されてる? Javaでやらないようなことはやらんほうがいい? 条件カッコに改行ありで詰め込むべき? そういうのはRubyでやれや!って煽られて終わりな気も致しますよ えーそれ言語関係なくない? hogeIsEmptyな関数に抽出するのは リファクタリングの基本だしJavaでもやるだろ むしろJavaだとboolean isHogeEmpty()ってメソッドを作るケースだから Javaの文法が古臭いと仕切り直したKotlinではメソッドを作らないのが正当なんじゃないの そうなのか? うーん。なんだったらgetだけのプロパティ作ってその中でやるという手もあるが。 >>684 変数での分離で良い 一見で意味付けが分かり辛いものは変数名で説明していい 局所的なものであれば無意味にメソッド化する必要も無い その条件式が2度出てきたときに再考する あー、rubyは変数いきなり定義だし命名規則もsnake_caseで緩いし変数もメソッドも呼び出し方同じにできるし 真偽には?つけてよいという風潮があるからこういうの得意だね Java/Kotlinは読み下しさせようとするとわりとデコボコするけどそのかわり静的コンパイルだから実行パフォーマンスへの影響が少ない (だから「ちょっと動かして見やすく名前つけただけで動作的中身的には一緒だから安心して」という説得に向いてるのはKotlinのほうではある) Kotlinにはスコープ関数とかletとかitとか(あとはbeがあれば完璧だ)あるのでそのへん駆使してもらうしか 一般的には説明変数を追加するのに比べると メソッド抽出のほうが可読性も保守性も高い デメリットもあるから状況次第で選択すればいい いずれにしても言語に依存した話ではないよ 言語に関係ない話だと思うんだけどごめん 初心者がゲーム作ってて、たとえばRPGのアイテムみたいなのをクラスで実装したいって考えたとき、 たとえば食べ物アイテムを100個くらい作ろうと思ったら、名前とか重さとか売価とかレシピとかを持ってるクラスが(下手するとktファイルも)それだけで100個あることになるよね 何かアイテムのデータを確かめたいとか書き換えたいとか思ったら100個の中から探さないといけなくなる気がして、とてもしんどいんだけど、なにか便利な管理方法ってあるものなのかしら でもデータベースはメソッド生えないにゃん… 現状の超でっかいMapオブジェクト {"yakusou" -> {"name":"薬草", "price":10, "weight":2, "action":["EAT","DROP","HEAL","GRIND"]...}} の該当アイテム読んでactionで分岐するメソッド構成とあんまし変わらない気がするにゃん… ビルド時にCSVファイルとかからクラスファイルを生成してもらえばいいのではと思ったけど 書いてるときにアイテムのクラスやメソッドが参照できないとIDEが補完警告出すことに気づいてぐにょーんってなってる たぶんゲーム特有のなんとかかんとかなんだろうと思うのでなんとかする >>695 アイテムごとに個別のメソッドが必要だと考えるのは抽象化が不足してるから 食べ物アイテム100個作っても食べ物クラス1個で済む場合もあるでしょ むしろそれぞれクラス化するのはアクションの方で アイテムなんて1クラスで十分じゃね >>695 > {"yakusou" -> {"name":"薬草", "price":10, "weight":2, "action":["EAT","DROP","HEAL","GRIND"]...}} > の該当アイテム読んでactionで分岐するメソッド構成とあんまし変わらない気がするにゃん… それの何がいけないの? 色々用途や効果がある個々のアイテムインスタンスが対応するメソッドを持ってて自分に関することは全て知っていて たとえば砕いたら何になるのかとか、字面に置いたらどのテクスチャになるのかとか、を問い合わせる構造にしたいのはわかる気がする でもそれ理想っぽいけどお察しの通りデータ増えると破綻するんすよ… よくわかんないけどデータベース(SQL)から(id,)name,price,weight,actionの(データ)クラスに入れてMapに突っ込むのは普通じゃね アクションは共通の動作だけハンドラーに直接書いて、固有の動作は個々のアイテムごとにスクリプトファイル作ってそんなかにアクションごとのメソッド書いて、それをハンドラーから実行させる あ 完全にサーバー<=>クライアント型のゲームを想定してました忘れてください よっぽどドラクエ2みたいなツクールサンプル的な単一用途アイテムでもない限り 「薬草という多用途アイテムを表現するのに薬草クラスのインスタンスを作って保持する」というのは悪手 このへんは個別に考えてもらわなければならないのでまあ結論としては>>699 個々人が下手に作って再発明して失敗して適応適用していかなきゃならんなんてなんて非効率なんだとは思うのだが今のところ光明はない ぶっちゃけ初心者にゲーム作らせるのこのへんの問題もあってあんま好きではないのだ。ユーティリティアプリが無難 薬草を使った時の処理 薬草を燃やした時の処理 薬草を売った時の処理 … 薬草クラスにまとめようがまとめまいが いずれはどこかに書かなければならない だったら最初から薬草クラスに入れとけって話 アルゴリズムと計算量を知らないのか 千個の中から、1つを見つける際、全(線形)探索なら千回、 2分探索なら、2^10 = 1,024 だから、10回で見つけられる 2分探索なら、データ数が千個でも、探索回数は、1/100 になる 2千個になっても、全(線形)探索なら2千回、 2分探索なら、11回で見つけられる。 探索回数は、1/200 になる データ数が倍になっても、探索回数は1回しか増えないが、 データを2分木で持っていないと、2分探索はできない ゲームでマスタ類はID(=index)でアクセスするので計算量はO(1) そして>>693 の話なら探すのは開発者なのでデータ化してメンテ画面作れという話になる 一覧で管理したくなる量のデータ(とそれに紐づいた処理)のクラスをいちいち手作業で作るのが面倒大変だけどこれでいいのかなって話なんじゃないの 前が見えなくなる人は迷惑だな JVMにはJAXBとかいう古き良きアーキテクチャがあってだな・・・ XMLだろうが、CSVだろうが、DBだろうが、(データ)クラスだろうが、どこに置くかは好みよね オブジェクト指向で親クラスにユーティリティ共通メソッド置くか 関数型でユーティリティクラスに共通関数置くかも多分好みの範疇だろうよ その上で、Kotlinだと何が流行りなの?(データ)クラス+関数型が流行り? DB だと、B-tree, B+ tree 計算量は、O(log n) 全(線形)探索なら、O(n) 計算量は、>>707 に書いた通り n = 100万なら、全探索で、100万回掛かるところが、 2分探索では、2^20 = 100万だから、20回 データを2分探索木で構築していないのなら、DB には勝てない 100個のインスタンスを、生成しただけだろ? Map(key : value) になっていないだろ? Map なら、O(1) だけど >>716 二分探索木じゃなくても二分探索はできるだろ >>710 の親切なツッコミをスルーして無駄レスすんなよ >>714 も無視しないほうがいいような気がする jarファイル中のクラスファイル検索なんて1万でもさして問題にならん(さすがに作成は人間の仕事ではないが) そして問題はそこではなかった 理解できなくなっちゃったんだろうけど JRE8では何ともなかったのにJRE9だとWARNING吐くようになったのは仕様? Kotlinを最新の1.1.51にしても直らなかった。 Androidの場合は全参照メソッド数が65536超えるとコンパイル不可能になるという問題が一応あるぞ つらいMultiDex使う羽目になるので「どうぐぜんぶにめそっどがはえてるおぶじぇくとしこうてきにただしいくらす」以外のアプローチも初期からご検討いただくと幸いだ >>723 インタプリタにて↓ >>> println("hogehoge") println("hogehoge")WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.intellij.util.text.StringFactory to co nstructor java.lang.String(char[],boolean) WARNING: Please consider reporting this to the maintainers of com.intellij.util. text.StringFactory WARNING: Use --illegal-access=warn to enable warnings of further illegal reflect ive access operations WARNING: All illegal access operations will be denied in a future release hogehoge 二度目以降は正常↓ >>> println("hogehoge") println("hogehoge")hogehoge kotlinって自作例外を「アプリ内事象○○のせいで完了できなかったんで3つくらい上の自作catchで捕まえて処置よろしこ」程度のメッセージ的に気軽に使ってもいい? 外部提供APIとかじゃなく、自作のプログラム内での処理依頼のやり取り用 String, char[] が異なる型なのかも 文字配列は、C言語の、\0 終端文字列かな? String型は高機能な、C++のString型かな? kotlinの技術書って、何で未だに日本向けのは一冊しか出てないの? 最近のAndroidはmultidexしなくても動くし、minSdkVersionを低く指定したら勝手にmultidexでバイナリ作られるから考慮するの無駄 というのは置いておいて、Java9のModule(Project Jigsaw)でアクセスコントロールが強化されて不正なリフレクションに対して警告出してるんじゃね 将来的には警告じゃなくエラーになりそうな気がするから、Kotlinのバージョンアップで直るのを待つべ >>730 まだあまり流行ってなくて出版社が乗り気じゃないのでは? 流行っているかどうかは、掌田津耶乃が判断する。 このおっさんが本を出す分野は、流行っていると言える このおっさん1人で、プログラミングの約半分の分野を、網羅しているw これか。10月6日発売。 Kotlin Webアプリケーション 新しいサーバサイドプログラミング http://amzn.asia/aQkmPNJ Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016 Kotlin Webアプリケーション 新しいサーバサイドプログラミング、長澤 太郎、2017/10/6 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる