Kotlin 2

**デフォルトの名無しさん** · 2017/11/01(水) 00:07:43.82

JetBrainsが開発した期待の新言語Kotlinについて語りましょう
https://kotlinlang.org

前スレ
Kotlin
http://mevius.5ch.net/test/read.cgi/tech/1456505161/

**デフォルトの名無しさん** · 2018/01/10(水) 07:32:55.52

もちろんSuperClassはopen指定してあります。
>>352 に答えられる人にそんな野暮なこと言う方はいないと思いますが念のため。

In Actionには「インターフェースを実装しいているなら〜」とさらっと書いていて
クラスでdelegateできない理由は触れられていませんでした。

**デフォルトの名無しさん** · 2018/01/10(水) 21:04:38.05

androidにdelegateなんて言葉はない

**デフォルトの名無しさん** · 2018/01/10(水) 22:52:38.58

>>352-353
例えばこんな感じのKotlinコードをJavaへ変換してみればわかる
interface Interface1 { ... }
interface Interface2 { ... }
class SubClass (impl1:Interface1, impl2:Interface2) : Interface1 by impl1, Interface2 by impl2

**デフォルトの名無しさん** · 2018/01/11(木) 06:56:39.64

>>355 ありがとうございます。
interface Interface1 { ... } が
open class Interface1 { ... } であったとしても、
class SubClass extends Interface1 implements Interface2
になるので、支障ないと思うのですが、どこか勘違いしていますでしょうか。

**デフォルトの名無しさん** · 2018/01/11(木) 07:43:33.12

>>356
ごめん多重継承は関係無かったね
問題になるのはコンストラクタかな
class SubClass extends SuperClass というJavaコードに相当するものに変換されるからには
SuperClass のコンストラクタを呼ぶ必要があるけど、
でも SuperClass by instance によってインスタンスが別に渡されたらSuperClassの実体が二つになってしまう

**デフォルトの名無しさん** · 2018/01/11(木) 10:00:24.62

>>352
インターフェースでないと移譲が保証出来ないからでは

インターフェースと違ってクラスの場合はそれが持つオーバーライド可能なメンバ全て移譲しても移譲になるとは限らない
例えば、あるライブラリがInterface, SuperClass, それらを引数に取る関数を提供しているとする
Interfaceを受け取るならInterfaceとして扱うべき
（内部の実装クラスへダウンキャスト出来ること等を前提とすべきでない）で、
SuperClassを受け取る場合も同様だが
こちらはprivateメンバへのアクセスなども含まれていてそれは移譲出来ない

**デフォルトの名無しさん** · 2018/01/12(金) 02:36:59.71

>>352
abstractやclassじゃextendsになっちゃうじゃん
したいのはimplementsじゃん
だからOnly interfaces can be delegated toって言われちゃうんだよ

**デフォルトの名無しさん** · 2018/01/12(金) 17:51:43.69

>>357の言いたかったこととは違うかもしれませんが、以下のように理解しました。

KotlinのdelegateはIn ActionではCollectionを引き合いに出しているが、
実際には、実装したクラスのコンストラクタがprivateで、
ヘルパークラスのファクトリメソッドを通じてしかインスタンスを生成できない
ようなケースで力を発揮する。

コンストラクタがpublicでopenなclassやabstractの場合、素直に継承することを想定している。
In Actionの例も(共変とか反変とかを抜きにすれば)実はArrayListの継承で解決できる。

逆に、classでのdelegateを認めるとfinalなclassも継承できてしまい、
これを禁止するために規則を増やすことになる。

>>359
書き込んだ動機としては、多数のプロパティを持ったクラスを継承したい時に、
class SuperClass(val comp1: Comp1, val com2: Comp2, ...)
class SubClass(instance: SuperClass) : SuperClass(instance.comp1, instance.comp2,...)
とすると、かなり宣言が不格好になるので、
class SubClass(instance: SuperClass) : SuperClass by instance
としたかったのです。

>>358
SuperClass内のSuperClassを引数に取る関数は、
SubClassにおいても引数としてSuperClassを渡せば正しく動作するので、
private(あるいはprotected)メンバへのアクセスがなくても、
実装可能でないかと思います。

ご指摘で理解できていない点があればご指摘いただければ幸いです。

皆様ありがとうございました。

**デフォルトの名無しさん** · 2018/01/12(金) 19:14:43.07

interface InterfaceClazz{
val comp1:Any
var comp2:Any
fun method1()
}
class SuperClazz(override val comp1: Any, override var comp2: Any) :InterfaceClazz {
override fun method1() {
println("SuperClazz.method1 comp1:$comp1 comp2:$comp2")
}
}

class SubClazz(instance:SuperClazz):InterfaceClazz by instance
こういうのじゃだめなの？

**デフォルトの名無しさん** · 2018/01/12(金) 22:32:24.26

>>361
自分が作ったクラスの場合ならそうできることは考えましたが、
他人がinterfaceを定義せずに作ったクラスでやりたい場合どうすればいいんだろうという疑問でした。

**デフォルトの名無しさん** · 2018/01/13(土) 08:10:52.44

Java, C# が、interface を作った理由は、
C++ のclass の、ひし形の形になる、ダイヤモンド継承を嫌ったから

ほとんどの言語は、単一継承 + interface。
継承チェーンに、同じクラスが現れると困る

親クラス ← 子クラス1・2 ← 孫クラス

孫クラスが、子クラス1・2を多重継承すると、
両方の子クラス部分に、親クラスのメンバ変数を含んでしまう

孫クラスからすると、どちらの子クラス経由で、
親クラスのメンバ変数にアクセスすべきか、ややこしい

だから多重継承用に、メンバ変数を持たず、メソッドだけを持つ、interface が作られた

is-a・class・継承よりも、has-a・interface・委譲の方が、柔軟性があって好まれる

**デフォルトの名無しさん** · 2018/01/13(土) 10:05:52.35

複数のinterfaceでメソッド名が被ってたらどうするの？

**デフォルトの名無しさん** · 2018/01/13(土) 10:11:05.35

そんな事態見たことないけど確かにどうなるんだ？

**デフォルトの名無しさん** · 2018/01/13(土) 10:23:17.39

パッケージ名とinterface名で指定するんじゃね

**デフォルトの名無しさん** · 2018/01/13(土) 11:09:24.85

>>364
実装はサブクラス側でやるんだからどうもなんねーだろ

**デフォルトの名無しさん** · 2018/01/13(土) 12:17:34.58

delegataion 使った >>355 みたいなので Interface1 と Interface2 に同じメソッドが定義されている場合にはエラーになるけど、
SubClass で override しろって IDE が言ってくるので、それすればエラーは消える
delegatation 使わないのなら >>367 が言うようにサブクラスで実装するんだから関係無いね

**デフォルトの名無しさん** · 2018/01/13(土) 12:18:29.46

Delegataion ってなんだ・・・Delegation ね

**デフォルトの名無しさん** · 2018/01/18(木) 20:57:21.62

coroutine builderの例えばasyncの定義を見ると、
fun <T> async(
context: CoroutineContext = DefaultDispatcher,
start: CoroutineStart = CoroutineStart.DEFAULT,
parent: Job? = null,
block: suspend CoroutineScope.() -> T
): Deferred<T> (source)
ってなってんですが、blockパラメータの型が関数型になっているのですが、
型の前にCoroutieScope.とかついてるのですが、これはなんなんでしょうか？？

**デフォルトの名無しさん** · 2018/01/18(木) 22:13:56.56

>>370
block内でのthisがその型のインスタンスになる
例
https://ideone.com/KsS26N

**デフォルトの名無しさん** · 2018/01/18(木) 22:42:32.43

>>371
ありがとうございます。

うーん。ややこしい。何のためにこんなのが必要なんだ・・
呼び出される関数の方でもインスタンス(val a = A("aa"))を作って
関数を呼び出さないといけないってことですよね。

**デフォルトの名無しさん** · 2018/01/18(木) 23:47:50.82

>>372
基本的にはDSL用の機能だと思う
https://ideone.com/CGz7Fp
https://kotlinlang.org/docs/reference/type-safe-builders.html

**デフォルトの名無しさん** · 2018/01/22(月) 22:47:52.97

delegateってパフォーマンス悪かったりします?
>>361のような方法を試したら、目に見えて遅くなりました。
もっとも他にも色々いじった後だから、他が原因の可能性もありますが....。

**デフォルトの名無しさん** · 2018/01/23(火) 18:27:08.00

仕組み的に体感出来る程の劣化は起きないと思う

**デフォルトの名無しさん** · 2018/01/23(火) 19:46:07.93

エルビス式のエルビスって何ですか？プレスリーしか出てこないんですけど

**デフォルトの名無しさん** · 2018/01/23(火) 19:47:46.14

と思ってググったら本当にプレスリー由来だったのね、、

**デフォルトの名無しさん** · 2018/01/23(火) 23:26:39.49

>>375
調べてみたら、delegateよりも前に速度低下はあったようでした。ありがとうございました。

**デフォルトの名無しさん** · 2018/01/24(水) 07:00:29.98

?: これのどこがプレスリーなんだよ？と思った時の脳内に浮かんでいたのはサタデーナイトフィーバーの人だったのは俺だけだろうな

**デフォルトの名無しさん** · 2018/01/24(水) 09:46:01.11

？：）

**デフォルトの名無しさん** · 2018/01/24(水) 12:18:03.47

?が5

**デフォルトの名無しさん** · 2018/01/31(水) 15:59:06.95

>>161だけど
Javaのリリースサイクルが6か月ごとになったので2018/3/20リリース予定
http://openjdk.java.net/projects/jdk/10/
ローカル変数の型推論きたー

後はGoogleさん早めにAndroidで使えるように。

**デフォルトの名無しさん** · 2018/01/31(水) 16:05:14.51

後はkotlinを使ってみて自分的にうらやましのは
・Null safety
・１ファイルに複数のクラス書ける
・コルーチン
ぐらいかな・・

**デフォルトの名無しさん** · 2018/01/31(水) 18:17:51.93

俺は
・val
・最後の引数のラムダを括弧の外に書けること
・「==」でnull考慮込みのequals()呼び出しにしてくれること

**デフォルトの名無しさん** · 2018/01/31(水) 18:53:28.83

とにかくJavaと同じことをするのに記述量が圧倒的に少なくて済むのが良いわ。

一つ一つはそれこそ数行程度の違いになるけど、チリが積もって最終的にかなり短くなって可読性が段違い

**デフォルトの名無しさん** · 2018/01/31(水) 20:20:09.40

Sから始まる某言語と違って何故か読みやすい

**デフォルトの名無しさん** · 2018/01/31(水) 20:58:06.42

Smalltalkの悪口はやめろ

**デフォルトの名無しさん** · 2018/01/31(水) 21:14:03.77

俺のS言語が・・・

**デフォルトの名無しさん** · 2018/01/31(水) 23:02:47.38

SQL

**デフォルトの名無しさん** · 2018/02/01(木) 07:20:22.31

Objective-Cを経験すれば大抵の言語は涙が出るほど読みやすい

**デフォルトの名無しさん** · 2018/02/01(木) 07:42:19.46

Schemeの悪口？

**デフォルトの名無しさん** · 2018/02/01(木) 08:58:05.91

perl「せやな」

**デフォルトの名無しさん** · 2018/02/01(木) 23:11:28.90

>>390
現役言語じゃないからもう新たに触ることないしなあ

**デフォルトの名無しさん** · 2018/02/01(木) 23:15:10.58

そういえば Objective-C ってMacとかiOSで使われてるんだっけ？

**デフォルトの名無しさん** · 2018/02/01(木) 23:28:46.21

MacとかiOSでしか使われていない

**デフォルトの名無しさん** · 2018/02/02(金) 01:47:08.99

SwiftはiOSでしか使われていない

**デフォルトの名無しさん** · 2018/02/02(金) 05:20:56.67

いくらいい言語でも林檎様の傘下だと何されるかわからんからな
使えねーわ

**デフォルトの名無しさん** · 2018/02/02(金) 07:12:32.55

swiftってオープンソースじゃなかったっけ？

**デフォルトの名無しさん** · 2018/02/02(金) 08:41:42.94

Swiftはオープンソース化以降は言語開発もコミュニティベースで行われてる
頑張ってはいるようだけどいくつかの問題でObjCに戻る人も割と居るし
クロスプラットフォーム系との競合もあって人気は減少傾向

**デフォルトの名無しさん** · 2018/02/02(金) 08:43:29.60

Kotlinの方がよくできてる

**デフォルトの名無しさん** · 2018/02/02(金) 09:20:26.67

Kotlinでのクロスプラットフォームは Kotlin/Native(まだベータ) と Multi-OS Engine があるけど
UI部分が固有になるから React NativeのKotlin版のような
UIブリッジするライブラリが生まれてほしい
WebViewも手だけど

**デフォルトの名無しさん** · 2018/02/02(金) 09:22:41.58

JavaScriptエンジンを挟みたくない

**デフォルトの名無しさん** · 2018/02/02(金) 12:06:11.99

C#でええやん

**デフォルトの名無しさん** · 2018/02/02(金) 12:35:18.11

コミュニティの条件に収まらなくてサブスクリプションが要る都合でそっちは二の足
言語自体は割と好きだけど

**デフォルトの名無しさん** · 2018/02/02(金) 19:53:43.35

何年か前はiOSとandroidのクロスプラットフォーム開発はいまいちすぎて結局それぞれネイティブて開発したけど、今はどうなんだろうな
最近スマホアプリさわらんからよくわからん

**デフォルトの名無しさん** · 2018/02/02(金) 21:37:32.04

あ、そうだ。iOSやMacの開発にKotlin使えれば全て丸く収まるじゃねえか。
MacだけならJREあるから既に動くのかな？

**デフォルトの名無しさん** · 2018/02/02(金) 21:43:50.82

Android studioはMac版もあるし当然Kotlinも使える
ただ、iPhoneアプリは作れねぇ

**デフォルトの名無しさん** · 2018/02/02(金) 22:32:37.72

>>406
MacとiOSはMacが無いとコンパイルすら出来ないって糞みたいな仕様が一番のネックだからな

**デフォルトの名無しさん** · 2018/02/02(金) 22:38:07.24

Windowsもネイティブアプリはそうだろ？　違うっけ？

**デフォルトの名無しさん** · 2018/02/02(金) 23:17:28.47

クロスプラットフォームは糞

**デフォルトの名無しさん** · 2018/02/02(金) 23:39:49.14

Xamarin C#が正解

**デフォルトの名無しさん** · 2018/02/03(土) 00:17:14.67

ちょまど教の狂信者か

**デフォルトの名無しさん** · 2018/02/03(土) 02:29:40.70

Xamarin程の糞はない
C#も10年前の時代遅れの言語だし圧倒的にswift,Java,Kotlinの方が人気が高いし求人も多い
VS for Macはgitでブランチを切り替えたりするだけでビルドできなくなって、
クリーン、リビルド、ＩＤＥ再起動、ＰＣ再起動を頻繁に繰り返さないといけなくなる欠陥品なのが糞
大体MicrosoftはWindowsPhoneのシェアを二桁取ってからモノを言えと言いたい
MicrosoftがやっていることはGoogleやAppleの作ったパイを横取りしようとしているだけ
MVVM前提の開発環境とか言うくせに外部ライブラリを入れないと良い感じでMVVMできないのが糞
ＵＩは共通化できると言うわりにListViewは重くてスワイプがもたついたり画像の表示が遅かったりするのが糞
Xamarin.Formsはちょっと複雑なことしようとするとお得意のdependency serviceとcustom rendererの連発
クロスプラットフォームと言うならXamarin.Formsだけでできないことを恥じろよ
WebViewなどXamarin.Formsの提供するUI部品が糞すぎて
一旦Xamarin.Formsの提供する機能で実装して糞な思いをさせられた後で
Xamarin.AndroidとXamarin.iOSで計3回も同じ実装をさせられるのが糞
Xamarinなんてマイナーな環境使っている人が少ないせいでググって調べものするのに時間がかかるのが糞
qiitaやstackoverflowの情報もXamarinに関するものはAndroidの10分の1以下の投稿しかなくて
下手すると解決策が見つからなくてデザインや機能の面で妥協する結果となる
任天堂のXamarin製アプリもカブドットコムのXamarin製アプリも星平均3.0の糞アプリ認定されてる
MicrosoftのAndroid向けedgeブラウザもXamarin製でなく、
Microsoft自身も糞認定して使わない糞開発環境がXamarin
エンジニアもデザイナーもお客さんも全員がっかりするのがXamarin
結論としてXamarinを使うと開発工数は伸びアプリのクオリティは落ちるということ
XamarinをやっているやつというのはC#の機能を使うことやXamarinを使うことそれ自体が目的化していて
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために
行われることであるべきで、完全に自分本位でゴミを量産し続けるXamarinエンジニアは全員死んだ方が良い

**デフォルトの名無しさん** · 2018/02/03(土) 08:57:07.88

>>413
KotlinもUIはJVM, JS, Nativeとそれぞれ開発しないといけないという方向性なんだよね。
マルチプラットフォームでUIもKoltinで1回書くだけで済む日は来ないんだろうか。
>>406
Gluonという会社がAndroidとiOS向けのJVM(JavaFX付き)を作るとか言っていたんだけどどうなったのかな。
ページを見に行くとあるにはあるっぽい。
使った人とかいます?

**デフォルトの名無しさん** · 2018/02/03(土) 09:01:37.02

>>406
Macだけなら余裕。
TornadoFXであっさり作れる。

**デフォルトの名無しさん** · 2018/02/03(土) 09:18:56.79

>>406 >>407
KotlinでiPhoneアプリは作れる

**デフォルトの名無しさん** · 2018/02/03(土) 09:33:24.43

参考

Android・iOS対応のクロスプラットフォームライブラリ、Intel Multi-OS Engine(MOE)
https://qiita.com/yyYank/items/2d96640d713a527691be

Kotlin/Nativeを使ってiOSアプリを作ってみる
https://qiita.com/noripi/items/4ee969c48b3da5ca6fbd

**デフォルトの名無しさん** · 2018/02/03(土) 09:37:01.92

面倒くさそう

**デフォルトの名無しさん** · 2018/02/03(土) 09:45:23.72

>>418
面倒なら
　・SwiftやObjective-Cで直に作る
　・Cordovaなどで作る
　・iPhoneアプリは諦める
詳細は該当のスレでどうぞ

**デフォルトの名無しさん** · 2018/02/03(土) 09:50:47.55

>>417
こんなんあるのか、知らなかった。試してみるよありがとう。
ただクロスプラットフォームのライブラリって大体最終的にうまくいかないから、つい警戒してしまうw

**デフォルトの名無しさん** · 2018/02/03(土) 10:04:18.17

Xamarin C#が正解だよ
簡単で高品質

**デフォルトの名無しさん** · 2018/02/03(土) 11:58:07.39

時間掛かって低品質のアプリが出来上がるだけクロスプラットフォーム

**デフォルトの名無しさん** · 2018/02/03(土) 12:05:11.68

正式セミナーで技術より人脈なんて宣伝する糞プラットフォームは使わない

**デフォルトの名無しさん** · 2018/02/03(土) 12:51:45.20

Xamarinは簡単だけど高品質かと言われると、、

**デフォルトの名無しさん** · 2018/02/03(土) 12:54:52.62

実際クロスプラットフォームが最適なアプリってそんな多くないよな。
何かの画像処理をするとかそういう端末内で複雑なビジネスロジックを組まなくちゃいけないものならそこを共通化できるメリットはあるだろうけど、
サーバーサイドと通信して何かをするのがメインなクライアント系アプリなら普通にネイティブで2つ作った方が楽

**デフォルトの名無しさん** · 2018/02/03(土) 13:19:34.45

Unityでええやん

**デフォルトの名無しさん** · 2018/02/03(土) 13:29:02.91

APIクライアントやちょっとした処理も完全に共通化できるから便利だよXamarin
Java,Kotlin / Swift,obj-cだと日付型と日付操作apiみたいな些細な部分でも違いがある
C#にすると文法や基本ライブラリの粒度で共通化できる

**デフォルトの名無しさん** · 2018/02/03(土) 13:58:55.43

C++使いなら、QTとかSDLとか

**デフォルトの名無しさん** · 2018/02/03(土) 14:47:37.76

Xamarinみたいな糞はプロトタイプ開発でしか使い道ない
まともなアプリはみんなネイティブ
任天堂のXamarin製アプリもカブドットコムのXamarin製アプリも星平均3.0の糞アプリ認定されてる
Microsoft自身も糞認定して使わない糞開発環境がXamarin

**デフォルトの名無しさん** · 2018/02/03(土) 15:38:21.40

Unityは日本語入力の問題さえ解決すれば多分かなりの部分の解決になると思う。
なんせ画面を描くところから自力でやってるからな。
業務アプリでもポチポチ画面押すだけの物とか結構いけると思うし、実際あるんじゃないかな。

**デフォルトの名無しさん** · 2018/02/03(土) 15:57:45.75

共通部分はともかくUiはそのプラットフォームのネイティブでやったほうが結局は簡単なんだよな

**デフォルトの名無しさん** · 2018/02/03(土) 16:06:38.75

どのプラットフォームでもネイティヴで書いてもVとVMは普通に分離するだろ
なんでマルチプラットフォーム対応で追加のコストはかからない

**デフォルトの名無しさん** · 2018/02/03(土) 16:32:01.67

>>430
おう業務アプリと入力フォーム部品の蜜月性なめんあ
Unityはゲームと家庭向けアプリ特化の方向性のままでいいと思うぞ

**デフォルトの名無しさん** · 2018/02/03(土) 18:14:08.46

クロプラは凝ったことしようとすると詰むね

**デフォルトの名無しさん** · 2018/02/03(土) 18:35:13.80

Xamarin程の糞はない

**デフォルトの名無しさん** · 2018/02/03(土) 18:46:40.72

>>433
確かにそうか。
社内カレンダー通りの休日がマークされる日付選択とか、営業日入力とか色々あるもんな。

**デフォルトの名無しさん** · 2018/02/03(土) 23:11:11.34

>>432
すまんけどそろそろXamarinスレに帰ってもらっていいかな

**デフォルトの名無しさん** · 2018/02/03(土) 23:47:52.38

ザマァw

**デフォルトの名無しさん** · 2018/02/03(土) 23:53:32.22

Xamarinで全てが解決する

**デフォルトの名無しさん** · 2018/02/04(日) 00:09:06.97

ざまりんは座間市のマスコットキャラクターです

**デフォルトの名無しさん** · 2018/02/04(日) 01:24:03.44

>>417
MOE ART って、もう狙ったネーミングとしか思えない。

**デフォルトの名無しさん** · 2018/02/04(日) 01:28:27.34

ざまりんとことりん・・・りん繋がりか

**デフォルトの名無しさん** · 2018/02/04(日) 09:35:33.76

>>442
どう考えてもことりんの方がかわいい

**デフォルトの名無しさん** · 2018/02/04(日) 09:54:33.07

クマリンだと税金までとってくれる

**デフォルトの名無しさん** · 2018/02/04(日) 09:57:33.79

今更だけど、ことりんとこっとりんどっちが正しいんだろ

**デフォルトの名無しさん** · 2018/02/04(日) 10:25:02.12

XamarinをやっているやつというのはC#の機能を使うことやXamarinを使うことそれ自体が目的化していて
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために
行われることであるべきで、完全に自分本位でゴミを量産し続けるXamarinエンジニアは全員死んだ方が良い

**デフォルトの名無しさん** · 2018/02/04(日) 11:57:10.52

ことりんの記述の簡潔さが良いと言われているスレに来てC#書けなんて言われたらそりゃ嫌がらせだよ

**デフォルトの名無しさん** · 2018/02/04(日) 12:57:23.44

C#の方がエレガントなコードを書けるでしょ
エレガントで保守性の高いプログラムはお客にとってもありがたい
お客にいいものを届けたいならXamarinだよ
Kotlinの奇形じみたセンスのない文法はお客も辟易してる
kotlinを使いたいというプログラマのわがままでお客に迷惑をかけちゃダメだ

**デフォルトの名無しさん** · 2018/02/04(日) 13:02:47.05

なんか変なのが居着いちゃったな。。。

**デフォルトの名無しさん** · 2018/02/04(日) 13:28:53.05

C#は、.Net か Monoを入れないといけないのがウザいし
JavaやKotlinは、JDK入れないといけないし、
やっぱそういう意味では、Swiftが最強やな

**デフォルトの名無しさん** · 2018/02/04(日) 13:45:15.33

ねーよ

**デフォルトの名無しさん** · 2018/02/04(日) 13:47:54.74

ことりんスレということを思い出していただきたい