JetBrainsが開発した期待の新言語Kotlinについて語りましょう
https://kotlinlang.org
前スレ
Kotlin
http://mevius.5ch.net/test/read.cgi/tech/1456505161/
Kotlin 2
■ このスレッドは過去ログ倉庫に格納されています
2017/11/01(水) 00:07:43.82ID:jxmKQQAl
322デフォルトの名無しさん
2017/12/20(水) 02:29:53.61ID:Y+OkZrNr マップの値を条件判定に使いたいんだけど、Nullableをどう扱って良いのかわからない...
val map = mapOf<String,Boolean>("hoge" to false,"fuge" to true,"piyo" to false)
// ↓こんな感じで書きたいが、Nullableなので怒られる
if (map["hoge"]){/*処理*/}
//---------- 解決策 ----------
// @強制的に!!でNotnullにする。でもなんか気持ち悪い。
if (map["hoge"]!!){/*処理*/}
// Aエルビス演算子を使う。しかし、IDEからBの書き方を提案される
if (map["hoge"] ?: false){/*処理*/}
// B凄いバカっぽい。ていうか、これOKで一番上ダメなんだ...
if (map["hoge"] == true){/*処理*/}
なんか、どれもしっくりこない。どうするのが正解なの....
誰か教えて!お願いします!
val map = mapOf<String,Boolean>("hoge" to false,"fuge" to true,"piyo" to false)
// ↓こんな感じで書きたいが、Nullableなので怒られる
if (map["hoge"]){/*処理*/}
//---------- 解決策 ----------
// @強制的に!!でNotnullにする。でもなんか気持ち悪い。
if (map["hoge"]!!){/*処理*/}
// Aエルビス演算子を使う。しかし、IDEからBの書き方を提案される
if (map["hoge"] ?: false){/*処理*/}
// B凄いバカっぽい。ていうか、これOKで一番上ダメなんだ...
if (map["hoge"] == true){/*処理*/}
なんか、どれもしっくりこない。どうするのが正解なの....
誰か教えて!お願いします!
323デフォルトの名無しさん
2017/12/20(水) 03:07:01.09ID:vJEKLhBA if (map.getOrDefault("hoge", false)) { ... } とか。
うーん。なんか変だね。mapOf では nullable かどうか判定しているのに get 時には nullable かどうかの情報が抜け落ちているような。
うーん。なんか変だね。mapOf では nullable かどうか判定しているのに get 時には nullable かどうかの情報が抜け落ちているような。
324デフォルトの名無しさん
2017/12/20(水) 03:12:58.65ID:O14cUYGW >>322
1はmap["hage"]とか存在しないキー指定すると落ちるだろ
2はエルビスで落ちないようになってて
3が落ちないのは、
ここ https://kotlinlang.org/docs/reference/equality.html
Structural equality あたりに書いてある仕組みのせいかな
どうmapを使えばいいのかは知らん
1はmap["hage"]とか存在しないキー指定すると落ちるだろ
2はエルビスで落ちないようになってて
3が落ちないのは、
ここ https://kotlinlang.org/docs/reference/equality.html
Structural equality あたりに書いてある仕組みのせいかな
どうmapを使えばいいのかは知らん
325デフォルトの名無しさん
2017/12/20(水) 03:15:09.91ID:O14cUYGW 知らんが、kotlinみたいな言語だとキーが無いときの処理を適当にごまかすわかにはいかんだろ
326デフォルトの名無しさん
2017/12/20(水) 03:31:33.35ID:nn3v7K50 >強制的に!!でNotnullにする。でもなんか気持ち悪い。
>if (map["hoge"]!!){/*処理*/}
そもそも、map は、そのキーが存在しない場合もあるのが、当たり前だろ。
そのキーが存在するかどうかを、チェックするメソッドもある
君が仕様・設計を考えるんだ。
1. そのキーが存在した場合の処理と、
2. 存在しなかった場合の処理
初心者は、強制変換の使い方をわかっていないのだから、!! を使うな
>if (map["hoge"]!!){/*処理*/}
そもそも、map は、そのキーが存在しない場合もあるのが、当たり前だろ。
そのキーが存在するかどうかを、チェックするメソッドもある
君が仕様・設計を考えるんだ。
1. そのキーが存在した場合の処理と、
2. 存在しなかった場合の処理
初心者は、強制変換の使い方をわかっていないのだから、!! を使うな
327デフォルトの名無しさん
2017/12/20(水) 03:56:24.26ID:MahKH8pr >>325
+1
「知らないキーでmapに問い合わせたときの結果はnullになることがある」問題をコード的になんとかする必要がどうしてもある
これは本当にどうしようもないので、どっかでKotlin(実際にはIDE)に知らせる面倒を許容するしかない
ポイントとしては面倒でも一旦変数にぶち込むこと。これですべてうまくいく
// checkNotNullの書き方だけ覚えればいいので最近全部これで書いてる
val mapValue: Boolean = checkNotNull(map["hoge"]){ "map does not have key:<hoge>" }
if (mapValue) { doSomething() }
// またletをそんな用途に使って
map["hoge"]?.let{ doSomething() }
// 考え方がJavaっぽい(偏見)変数に入れないとnullチェックした履歴保持できないよ
val mapValue = map["hoge"]
if (mapValue!= null && mapValue) { doSomething() }
// ほら、Kotlinの人はなんでもかんでもwhenで書きたがるから
when(map["hoge"]){
null -> println("ぬるぽ") // なくても動く
true -> doSomethingTrue()
false -> doSomethingFalse()
}
+1
「知らないキーでmapに問い合わせたときの結果はnullになることがある」問題をコード的になんとかする必要がどうしてもある
これは本当にどうしようもないので、どっかでKotlin(実際にはIDE)に知らせる面倒を許容するしかない
ポイントとしては面倒でも一旦変数にぶち込むこと。これですべてうまくいく
// checkNotNullの書き方だけ覚えればいいので最近全部これで書いてる
val mapValue: Boolean = checkNotNull(map["hoge"]){ "map does not have key:<hoge>" }
if (mapValue) { doSomething() }
// またletをそんな用途に使って
map["hoge"]?.let{ doSomething() }
// 考え方がJavaっぽい(偏見)変数に入れないとnullチェックした履歴保持できないよ
val mapValue = map["hoge"]
if (mapValue!= null && mapValue) { doSomething() }
// ほら、Kotlinの人はなんでもかんでもwhenで書きたがるから
when(map["hoge"]){
null -> println("ぬるぽ") // なくても動く
true -> doSomethingTrue()
false -> doSomethingFalse()
}
328デフォルトの名無しさん
2017/12/20(水) 04:24:12.03ID:MahKH8pr 寝起きで書いたら!=がくっついた
if (mapValue != null && mapValue) { doSomething() }
まだ頭寝てるので動作チェックしてないから細かいとこは適当に直したりしてくれ
>>326
安易に nullableValue?.let{ ... } を使って欲しくないのも似たような感じ
今回で言うと現在のmapに"hoge"が登録されていることの保証はどうするんだろうと思う
ぬるぽ出ると追うのもしんどいわけでさ
1行で済むし動作にも影響らしい影響はないんだから脳死状態で checkNotNull(...){ "やべえhoge登録されてねえ" } とか書いとくのおすすめしたいわ
if (mapValue != null && mapValue) { doSomething() }
まだ頭寝てるので動作チェックしてないから細かいとこは適当に直したりしてくれ
>>326
安易に nullableValue?.let{ ... } を使って欲しくないのも似たような感じ
今回で言うと現在のmapに"hoge"が登録されていることの保証はどうするんだろうと思う
ぬるぽ出ると追うのもしんどいわけでさ
1行で済むし動作にも影響らしい影響はないんだから脳死状態で checkNotNull(...){ "やべえhoge登録されてねえ" } とか書いとくのおすすめしたいわ
329デフォルトの名無しさん
2017/12/20(水) 07:46:04.79ID:nn3v7K50 map, hash は、集合の概念だから、
集合A に属するか属さないか、のどちらかの状態をとる
1. そのキーが集合A にあれば、値が取得できる
2. そのキーが集合A になければ、値が取得できない
1, 2 で、君がどういう処理をするか、仕様・設計を決めるのは君!
集合A に属するか属さないか、のどちらかの状態をとる
1. そのキーが集合A にあれば、値が取得できる
2. そのキーが集合A になければ、値が取得できない
1, 2 で、君がどういう処理をするか、仕様・設計を決めるのは君!
330デフォルトの名無しさん
2017/12/20(水) 07:49:29.92ID:f5FKKl5l331デフォルトの名無しさん
2017/12/20(水) 12:00:57.83ID:f5FKKl5l Bがバカっぽいと感じるのは
真偽値 == 真偽値 だと勘違いしているから
実際には2つのNullableTypeの等値比較
真偽値 == 真偽値 だと勘違いしているから
実際には2つのNullableTypeの等値比較
332デフォルトの名無しさん
2017/12/20(水) 13:02:21.99ID:G3r13eVw if(map.getValue("hoge")){/* 処理 */}
これで基本的にキーが存在しないと例外に行くしシンプルだね
これで基本的にキーが存在しないと例外に行くしシンプルだね
333デフォルトの名無しさん
2017/12/20(水) 13:25:19.85ID:g9yiCifS 直感的にはおかしく感じるな。(最初結果見た時は驚いたw)
https://paiza.io/projects/zLCe3AYlPO9luQp7z2NaIw
しかしクラスの参照同士の比較なのでこれで良い。
https://paiza.io/projects/zLCe3AYlPO9luQp7z2NaIw
しかしクラスの参照同士の比較なのでこれで良い。
334デフォルトの名無しさん
2017/12/20(水) 13:51:27.51ID:cc5ffQEu335デフォルトの名無しさん
2017/12/20(水) 13:54:26.10ID:f5FKKl5l >>333
おかしく感じたのはprintln("True")と書いたからじゃないの
not False と True は同義でないよ
https://paiza.io/projects/1WgctVAqXu8SWmlIYtx4YA
おかしく感じたのはprintln("True")と書いたからじゃないの
not False と True は同義でないよ
https://paiza.io/projects/1WgctVAqXu8SWmlIYtx4YA
336デフォルトの名無しさん
2017/12/20(水) 13:58:37.66ID:QHJO7UtC おまえがそう思うのならそうなのだろう。おまえの中ではな。
337デフォルトの名無しさん
2017/12/20(水) 15:20:49.03ID:g9yiCifS338デフォルトの名無しさん
2017/12/20(水) 16:11:14.74ID:skPFcOgX >>337
このコードだとFalse以外のAnyでは
このコードだとFalse以外のAnyでは
339デフォルトの名無しさん
2017/12/20(水) 16:17:54.73ID:f5FKKl5l340デフォルトの名無しさん
2017/12/20(水) 16:28:57.34ID:f5FKKl5l341デフォルトの名無しさん
2017/12/20(水) 18:13:04.50ID:oPcnMRgu342デフォルトの名無しさん
2017/12/20(水) 18:27:37.40ID:AIjICjtT 糞みてえな言語だな
343デフォルトの名無しさん
2017/12/20(水) 18:40:45.87ID:GLW9SuF+ Xamarin程の糞はない
344デフォルトの名無しさん
2017/12/20(水) 21:01:27.13ID:SZt84l7a 糞だからこそ良い
345デフォルトの名無しさん
2017/12/25(月) 05:24:40.47ID:CQjgWB2v やはりJavaを超えられなかったか。
346デフォルトの名無しさん
2017/12/25(月) 09:22:20.35ID:pKfklu/G \ ∩─ー、 ====
\/ ● 、_ `ヽ ======
/ \( ● ● |つ
| X_入__ノ ミ そんな餌で俺様が釣られクマ――
、 (_/ ノ /⌒l
/\___ノ゙_/ / =====
〈 __ノ ====
\ \_ \
\___) \ ====== (´⌒
\ ___ \__ (´⌒;;(´⌒;;
\___)___)(´;;⌒ (´⌒;; ズザザザ
\/ ● 、_ `ヽ ======
/ \( ● ● |つ
| X_入__ノ ミ そんな餌で俺様が釣られクマ――
、 (_/ ノ /⌒l
/\___ノ゙_/ / =====
〈 __ノ ====
\ \_ \
\___) \ ====== (´⌒
\ ___ \__ (´⌒;;(´⌒;;
\___)___)(´;;⌒ (´⌒;; ズザザザ
347デフォルトの名無しさん
2017/12/25(月) 14:41:12.11ID:eNXAkvu4 >>343
ちょまど神への信仰が不足しているか背教者ですね
ちょまど神への信仰が不足しているか背教者ですね
348デフォルトの名無しさん
2017/12/28(木) 18:16:09.77ID:xKYb+xvk >>278の本は何故か新品よりも高い中古がもう出ているw
(値段のタイプミスか?)
(値段のタイプミスか?)
349デフォルトの名無しさん
2017/12/28(木) 20:08:10.60ID:g7xH4Ri4 購入者の確認不足や品切れ時にたまたま買われることを狙った有名な詐欺だよ
350デフォルトの名無しさん
2017/12/29(金) 01:04:43.78ID:05sEmydS351デフォルトの名無しさん
2017/12/29(金) 10:11:40.46ID:RRbpiG2U >>350
盛ってるから問題ないで
盛ってるから問題ないで
352デフォルトの名無しさん
2018/01/10(水) 07:01:15.70ID:IyW1fpec classのdelegateってinterfaceしか出来ないみたいだけど、
classやabstractのインスタンスでdelegateできない理由をご存知の方いらっしゃいますでしょうか。
可: class SubClass(instance: Interface) : Interface by instance
不可: class SubClass(instance: SuperClass) : SuperClass by instance
classやabstractのインスタンスでdelegateできない理由をご存知の方いらっしゃいますでしょうか。
可: class SubClass(instance: Interface) : Interface by instance
不可: class SubClass(instance: SuperClass) : SuperClass by instance
353デフォルトの名無しさん
2018/01/10(水) 07:32:55.52ID:IyW1fpec もちろんSuperClassはopen指定してあります。
>>352 に答えられる人にそんな野暮なこと言う方はいないと思いますが念のため。
In Actionには「インターフェースを実装しいているなら〜」とさらっと書いていて
クラスでdelegateできない理由は触れられていませんでした。
>>352 に答えられる人にそんな野暮なこと言う方はいないと思いますが念のため。
In Actionには「インターフェースを実装しいているなら〜」とさらっと書いていて
クラスでdelegateできない理由は触れられていませんでした。
354デフォルトの名無しさん
2018/01/10(水) 21:04:38.05ID:CUBllmbw androidにdelegateなんて言葉はない
355デフォルトの名無しさん
2018/01/10(水) 22:52:38.58ID:68cAMYmT >>352-353
例えばこんな感じのKotlinコードをJavaへ変換してみればわかる
interface Interface1 { ... }
interface Interface2 { ... }
class SubClass (impl1:Interface1, impl2:Interface2) : Interface1 by impl1, Interface2 by impl2
例えばこんな感じのKotlinコードをJavaへ変換してみればわかる
interface Interface1 { ... }
interface Interface2 { ... }
class SubClass (impl1:Interface1, impl2:Interface2) : Interface1 by impl1, Interface2 by impl2
356デフォルトの名無しさん
2018/01/11(木) 06:56:39.64ID:irxu1jkK >>355 ありがとうございます。
interface Interface1 { ... } が
open class Interface1 { ... } であったとしても、
class SubClass extends Interface1 implements Interface2
になるので、支障ないと思うのですが、どこか勘違いしていますでしょうか。
interface Interface1 { ... } が
open class Interface1 { ... } であったとしても、
class SubClass extends Interface1 implements Interface2
になるので、支障ないと思うのですが、どこか勘違いしていますでしょうか。
357デフォルトの名無しさん
2018/01/11(木) 07:43:33.12ID:rggai+wG >>356
ごめん多重継承は関係無かったね
問題になるのはコンストラクタかな
class SubClass extends SuperClass というJavaコードに相当するものに変換されるからには
SuperClass のコンストラクタを呼ぶ必要があるけど、
でも SuperClass by instance によってインスタンスが別に渡されたらSuperClassの実体が二つになってしまう
ごめん多重継承は関係無かったね
問題になるのはコンストラクタかな
class SubClass extends SuperClass というJavaコードに相当するものに変換されるからには
SuperClass のコンストラクタを呼ぶ必要があるけど、
でも SuperClass by instance によってインスタンスが別に渡されたらSuperClassの実体が二つになってしまう
358デフォルトの名無しさん
2018/01/11(木) 10:00:24.62ID:J2rrbjux >>352
インターフェースでないと移譲が保証出来ないからでは
インターフェースと違ってクラスの場合はそれが持つオーバーライド可能なメンバ全て移譲しても移譲になるとは限らない
例えば、あるライブラリがInterface, SuperClass, それらを引数に取る関数を提供しているとする
Interfaceを受け取るならInterfaceとして扱うべき
(内部の実装クラスへダウンキャスト出来ること等を前提とすべきでない)で、
SuperClassを受け取る場合も同様だが
こちらはprivateメンバへのアクセスなども含まれていてそれは移譲出来ない
インターフェースでないと移譲が保証出来ないからでは
インターフェースと違ってクラスの場合はそれが持つオーバーライド可能なメンバ全て移譲しても移譲になるとは限らない
例えば、あるライブラリがInterface, SuperClass, それらを引数に取る関数を提供しているとする
Interfaceを受け取るならInterfaceとして扱うべき
(内部の実装クラスへダウンキャスト出来ること等を前提とすべきでない)で、
SuperClassを受け取る場合も同様だが
こちらはprivateメンバへのアクセスなども含まれていてそれは移譲出来ない
359デフォルトの名無しさん
2018/01/12(金) 02:36:59.71ID:EycqiUrc >>352
abstractやclassじゃextendsになっちゃうじゃん
したいのはimplementsじゃん
だからOnly interfaces can be delegated toって言われちゃうんだよ
abstractやclassじゃextendsになっちゃうじゃん
したいのはimplementsじゃん
だからOnly interfaces can be delegated toって言われちゃうんだよ
360デフォルトの名無しさん
2018/01/12(金) 17:51:43.69ID:to65cpCS >>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)メンバへのアクセスがなくても、
実装可能でないかと思います。
ご指摘で理解できていない点があればご指摘いただければ幸いです。
皆様ありがとうございました。
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)メンバへのアクセスがなくても、
実装可能でないかと思います。
ご指摘で理解できていない点があればご指摘いただければ幸いです。
皆様ありがとうございました。
361デフォルトの名無しさん
2018/01/12(金) 19:14:43.07ID:EycqiUrc 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
こういうのじゃだめなの?
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
こういうのじゃだめなの?
362デフォルトの名無しさん
2018/01/12(金) 22:32:24.26ID:to65cpCS363デフォルトの名無しさん
2018/01/13(土) 08:10:52.44ID:9rLeDqe4 Java, C# が、interface を作った理由は、
C++ のclass の、ひし形の形になる、ダイヤモンド継承を嫌ったから
ほとんどの言語は、単一継承 + interface。
継承チェーンに、同じクラスが現れると困る
親クラス ← 子クラス1・2 ← 孫クラス
孫クラスが、子クラス1・2を多重継承すると、
両方の子クラス部分に、親クラスのメンバ変数を含んでしまう
孫クラスからすると、どちらの子クラス経由で、
親クラスのメンバ変数にアクセスすべきか、ややこしい
だから多重継承用に、メンバ変数を持たず、メソッドだけを持つ、interface が作られた
is-a・class・継承よりも、has-a・interface・委譲の方が、柔軟性があって好まれる
C++ のclass の、ひし形の形になる、ダイヤモンド継承を嫌ったから
ほとんどの言語は、単一継承 + interface。
継承チェーンに、同じクラスが現れると困る
親クラス ← 子クラス1・2 ← 孫クラス
孫クラスが、子クラス1・2を多重継承すると、
両方の子クラス部分に、親クラスのメンバ変数を含んでしまう
孫クラスからすると、どちらの子クラス経由で、
親クラスのメンバ変数にアクセスすべきか、ややこしい
だから多重継承用に、メンバ変数を持たず、メソッドだけを持つ、interface が作られた
is-a・class・継承よりも、has-a・interface・委譲の方が、柔軟性があって好まれる
364デフォルトの名無しさん
2018/01/13(土) 10:05:52.35ID:RtHYbtnJ 複数のinterfaceでメソッド名が被ってたらどうするの?
365デフォルトの名無しさん
2018/01/13(土) 10:11:05.35ID:i594883x そんな事態見たことないけど確かにどうなるんだ?
366デフォルトの名無しさん
2018/01/13(土) 10:23:17.39ID:Rp7yFlms パッケージ名とinterface名で指定するんじゃね
367デフォルトの名無しさん
2018/01/13(土) 11:09:24.85ID:rLmRRKlD >>364
実装はサブクラス側でやるんだからどうもなんねーだろ
実装はサブクラス側でやるんだからどうもなんねーだろ
368デフォルトの名無しさん
2018/01/13(土) 12:17:34.58ID:7idPsqBM369デフォルトの名無しさん
2018/01/13(土) 12:18:29.46ID:7idPsqBM Delegataion ってなんだ・・・Delegation ね
370デフォルトの名無しさん
2018/01/18(木) 20:57:21.62ID:uaAP/nEg 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.とかついてるのですが、これはなんなんでしょうか??
fun <T> async(
context: CoroutineContext = DefaultDispatcher,
start: CoroutineStart = CoroutineStart.DEFAULT,
parent: Job? = null,
block: suspend CoroutineScope.() -> T
): Deferred<T> (source)
ってなってんですが、blockパラメータの型が関数型になっているのですが、
型の前にCoroutieScope.とかついてるのですが、これはなんなんでしょうか??
371デフォルトの名無しさん
2018/01/18(木) 22:13:56.56ID:h6w5lyYQ372デフォルトの名無しさん
2018/01/18(木) 22:42:32.43ID:uaAP/nEg >>371
ありがとうございます。
うーん。ややこしい。何のためにこんなのが必要なんだ・・
呼び出される関数の方でもインスタンス(val a = A("aa"))を作って
関数を呼び出さないといけないってことですよね。
ありがとうございます。
うーん。ややこしい。何のためにこんなのが必要なんだ・・
呼び出される関数の方でもインスタンス(val a = A("aa"))を作って
関数を呼び出さないといけないってことですよね。
373デフォルトの名無しさん
2018/01/18(木) 23:47:50.82ID:h6w5lyYQ374デフォルトの名無しさん
2018/01/22(月) 22:47:52.97ID:FT3BkIDm375デフォルトの名無しさん
2018/01/23(火) 18:27:08.00ID:himcush7 仕組み的に体感出来る程の劣化は起きないと思う
376デフォルトの名無しさん
2018/01/23(火) 19:46:07.93ID:leMx6cGU エルビス式のエルビスって何ですか?プレスリーしか出てこないんですけど
377デフォルトの名無しさん
2018/01/23(火) 19:47:46.14ID:leMx6cGU と思ってググったら本当にプレスリー由来だったのね、、
378デフォルトの名無しさん
2018/01/23(火) 23:26:39.49ID:9+CEbA1m >>375
調べてみたら、delegateよりも前に速度低下はあったようでした。ありがとうございました。
調べてみたら、delegateよりも前に速度低下はあったようでした。ありがとうございました。
379デフォルトの名無しさん
2018/01/24(水) 07:00:29.98ID:YOaqJu3C ?: これのどこがプレスリーなんだよ?と思った時の脳内に浮かんでいたのはサタデーナイトフィーバーの人だったのは俺だけだろうな
380デフォルトの名無しさん
2018/01/24(水) 09:46:01.11ID:yQK5cwW2 ?:)
381デフォルトの名無しさん
2018/01/24(水) 12:18:03.47ID:wZvPOi0Q ?が5
382デフォルトの名無しさん
2018/01/31(水) 15:59:06.95ID:4N9XMFe/ >>161だけど
Javaのリリースサイクルが6か月ごとになったので2018/3/20リリース予定
http://openjdk.java.net/projects/jdk/10/
ローカル変数の型推論きたー
後はGoogleさん早めにAndroidで使えるように。
Javaのリリースサイクルが6か月ごとになったので2018/3/20リリース予定
http://openjdk.java.net/projects/jdk/10/
ローカル変数の型推論きたー
後はGoogleさん早めにAndroidで使えるように。
383デフォルトの名無しさん
2018/01/31(水) 16:05:14.51ID:4N9XMFe/ 後はkotlinを使ってみて自分的にうらやましのは
・Null safety
・1ファイルに複数のクラス書ける
・コルーチン
ぐらいかな・・
・Null safety
・1ファイルに複数のクラス書ける
・コルーチン
ぐらいかな・・
384デフォルトの名無しさん
2018/01/31(水) 18:17:51.93ID:hwMh3j1W 俺は
・val
・最後の引数のラムダを括弧の外に書けること
・「==」でnull考慮込みのequals()呼び出しにしてくれること
・val
・最後の引数のラムダを括弧の外に書けること
・「==」でnull考慮込みのequals()呼び出しにしてくれること
385デフォルトの名無しさん
2018/01/31(水) 18:53:28.83ID:F5No3k5g とにかくJavaと同じことをするのに記述量が圧倒的に少なくて済むのが良いわ。
一つ一つはそれこそ数行程度の違いになるけど、チリが積もって最終的にかなり短くなって可読性が段違い
一つ一つはそれこそ数行程度の違いになるけど、チリが積もって最終的にかなり短くなって可読性が段違い
386デフォルトの名無しさん
2018/01/31(水) 20:20:09.40ID:CrWRl7VR Sから始まる某言語と違って何故か読みやすい
387デフォルトの名無しさん
2018/01/31(水) 20:58:06.42ID:UVbJv7LF Smalltalkの悪口はやめろ
388デフォルトの名無しさん
2018/01/31(水) 21:14:03.77ID:AX72W1bb 俺のS言語が・・・
389デフォルトの名無しさん
2018/01/31(水) 23:02:47.38ID:Mw3vWzBx SQL
390デフォルトの名無しさん
2018/02/01(木) 07:20:22.31ID:d+x91pir Objective-Cを経験すれば大抵の言語は涙が出るほど読みやすい
391デフォルトの名無しさん
2018/02/01(木) 07:42:19.46ID:XxNDw1fe Schemeの悪口?
392デフォルトの名無しさん
2018/02/01(木) 08:58:05.91ID:0qxcm1IL perl「せやな」
393デフォルトの名無しさん
2018/02/01(木) 23:11:28.90ID:PazMLs1n >>390
現役言語じゃないからもう新たに触ることないしなあ
現役言語じゃないからもう新たに触ることないしなあ
394デフォルトの名無しさん
2018/02/01(木) 23:15:10.58ID:oMkeAueE そういえば Objective-C ってMacとかiOSで使われてるんだっけ?
395デフォルトの名無しさん
2018/02/01(木) 23:28:46.21ID:xVAl4gBi MacとかiOSでしか使われていない
396デフォルトの名無しさん
2018/02/02(金) 01:47:08.99ID:sNIUDAKb SwiftはiOSでしか使われていない
397デフォルトの名無しさん
2018/02/02(金) 05:20:56.67ID:s78i1eOK いくらいい言語でも林檎様の傘下だと何されるかわからんからな
使えねーわ
使えねーわ
398デフォルトの名無しさん
2018/02/02(金) 07:12:32.55ID:gnaQFUD2 swiftってオープンソースじゃなかったっけ?
399デフォルトの名無しさん
2018/02/02(金) 08:41:42.94ID:V6ypn24z Swiftはオープンソース化以降は言語開発もコミュニティベースで行われてる
頑張ってはいるようだけどいくつかの問題でObjCに戻る人も割と居るし
クロスプラットフォーム系との競合もあって人気は減少傾向
頑張ってはいるようだけどいくつかの問題でObjCに戻る人も割と居るし
クロスプラットフォーム系との競合もあって人気は減少傾向
400デフォルトの名無しさん
2018/02/02(金) 08:43:29.60ID:2JRgrNpV Kotlinの方がよくできてる
401デフォルトの名無しさん
2018/02/02(金) 09:20:26.67ID:V6ypn24z Kotlinでのクロスプラットフォームは Kotlin/Native(まだベータ) と Multi-OS Engine があるけど
UI部分が固有になるから React NativeのKotlin版のような
UIブリッジするライブラリが生まれてほしい
WebViewも手だけど
UI部分が固有になるから React NativeのKotlin版のような
UIブリッジするライブラリが生まれてほしい
WebViewも手だけど
402デフォルトの名無しさん
2018/02/02(金) 09:22:41.58ID:V6ypn24z JavaScriptエンジンを挟みたくない
403デフォルトの名無しさん
2018/02/02(金) 12:06:11.99ID:jTuMDwxk C#でええやん
404デフォルトの名無しさん
2018/02/02(金) 12:35:18.11ID:V6ypn24z コミュニティの条件に収まらなくてサブスクリプションが要る都合でそっちは二の足
言語自体は割と好きだけど
言語自体は割と好きだけど
405デフォルトの名無しさん
2018/02/02(金) 19:53:43.35ID:YRu1rdgq 何年か前はiOSとandroidのクロスプラットフォーム開発はいまいちすぎて結局それぞれネイティブて開発したけど、今はどうなんだろうな
最近スマホアプリさわらんからよくわからん
最近スマホアプリさわらんからよくわからん
406デフォルトの名無しさん
2018/02/02(金) 21:37:32.04ID:00GaqTOE あ、そうだ。iOSやMacの開発にKotlin使えれば全て丸く収まるじゃねえか。
MacだけならJREあるから既に動くのかな?
MacだけならJREあるから既に動くのかな?
407デフォルトの名無しさん
2018/02/02(金) 21:43:50.82ID:zvuXw/YQ Android studioはMac版もあるし当然Kotlinも使える
ただ、iPhoneアプリは作れねぇ
ただ、iPhoneアプリは作れねぇ
408デフォルトの名無しさん
2018/02/02(金) 22:32:37.72ID:iI1eaKOA >>406
MacとiOSはMacが無いとコンパイルすら出来ないって糞みたいな仕様が一番のネックだからな
MacとiOSはMacが無いとコンパイルすら出来ないって糞みたいな仕様が一番のネックだからな
409デフォルトの名無しさん
2018/02/02(金) 22:38:07.24ID:zvuXw/YQ Windowsもネイティブアプリはそうだろ? 違うっけ?
410デフォルトの名無しさん
2018/02/02(金) 23:17:28.47ID:2JRgrNpV クロスプラットフォームは糞
411デフォルトの名無しさん
2018/02/02(金) 23:39:49.14ID:4J1UtiB3 Xamarin C#が正解
412デフォルトの名無しさん
2018/02/03(土) 00:17:14.67ID:Pk3rL+mD ちょまど教の狂信者か
413デフォルトの名無しさん
2018/02/03(土) 02:29:40.70ID:rIodJ30B Xamarin程の糞はない
C#も10年前の時代遅れの言語だし圧倒的にswift,Java,Kotlinの方が人気が高いし求人も多い
VS for Macはgitでブランチを切り替えたりするだけでビルドできなくなって、
クリーン、リビルド、IDE再起動、PC再起動を頻繁に繰り返さないといけなくなる欠陥品なのが糞
大体MicrosoftはWindowsPhoneのシェアを二桁取ってからモノを言えと言いたい
MicrosoftがやっていることはGoogleやAppleの作ったパイを横取りしようとしているだけ
MVVM前提の開発環境とか言うくせに外部ライブラリを入れないと良い感じでMVVMできないのが糞
UIは共通化できると言うわりに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エンジニアは全員死んだ方が良い
C#も10年前の時代遅れの言語だし圧倒的にswift,Java,Kotlinの方が人気が高いし求人も多い
VS for Macはgitでブランチを切り替えたりするだけでビルドできなくなって、
クリーン、リビルド、IDE再起動、PC再起動を頻繁に繰り返さないといけなくなる欠陥品なのが糞
大体MicrosoftはWindowsPhoneのシェアを二桁取ってからモノを言えと言いたい
MicrosoftがやっていることはGoogleやAppleの作ったパイを横取りしようとしているだけ
MVVM前提の開発環境とか言うくせに外部ライブラリを入れないと良い感じでMVVMできないのが糞
UIは共通化できると言うわりに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エンジニアは全員死んだ方が良い
414デフォルトの名無しさん
2018/02/03(土) 08:57:07.88ID:cx3bBBlj415デフォルトの名無しさん
2018/02/03(土) 09:01:37.02ID:w4Z6vlfg416デフォルトの名無しさん
2018/02/03(土) 09:18:56.79ID:JaWlScCi417デフォルトの名無しさん
2018/02/03(土) 09:33:24.43ID:JaWlScCi 参考
Android・iOS対応のクロスプラットフォームライブラリ、Intel Multi-OS Engine(MOE)
https://qiita.com/yyYank/items/2d96640d713a527691be
Kotlin/Nativeを使ってiOSアプリを作ってみる
https://qiita.com/noripi/items/4ee969c48b3da5ca6fbd
Android・iOS対応のクロスプラットフォームライブラリ、Intel Multi-OS Engine(MOE)
https://qiita.com/yyYank/items/2d96640d713a527691be
Kotlin/Nativeを使ってiOSアプリを作ってみる
https://qiita.com/noripi/items/4ee969c48b3da5ca6fbd
418デフォルトの名無しさん
2018/02/03(土) 09:37:01.92ID:cwvA0gbQ 面倒くさそう
419デフォルトの名無しさん
2018/02/03(土) 09:45:23.72ID:JaWlScCi420デフォルトの名無しさん
2018/02/03(土) 09:50:47.55ID:w4Z6vlfg421デフォルトの名無しさん
2018/02/03(土) 10:04:18.17ID:g4V8Xpml Xamarin C#が正解だよ
簡単で高品質
簡単で高品質
■ このスレッドは過去ログ倉庫に格納されています
