Kotlin 6

**デフォルトの名無しさん** · 2019/06/22(土) 15:59:57.23

JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう

※前スレ
Kotlin 5
https://mevius.5ch.net/test/read.cgi/tech/1544268581/

**デフォルトの名無しさん** · 2020/03/14(土) 08:50:35.96

>>712
・とにかく即動ける開発者を大人数集めないといけない場合
・約1MBのアプリサイズ増加が許容出来ない場合
ならJavaかな

**デフォルトの名無しさん** · 2020/03/14(土) 11:17:54.82

>>711
俺は特別！

**デフォルトの名無しさん** · 2020/03/14(土) 15:02:17.48

特別な俺に酔いしれる、アートなプログラミングをするスレ民にふさわしいな

**デフォルトの名無しさん** · 2020/03/15(日) 01:00:14.34

異端だな。
Androidアプリ作ってる場合はまあ普通だが。

**デフォルトの名無しさん** · 2020/03/15(日) 13:40:42.45

アンドロイドアプリ作る案件でしか触ったことないけどアンドロイドアプリ以外でもこの言語使うことってどれくらいあるんだ？
フリーでいろんな会社のいろんな案件に携わってきたけどアンドロイドアプリ以外でこの言語選択してるシステムに出会ったことがない

**デフォルトの名無しさん** · 2020/03/15(日) 13:43:15.79

SwiftもRustもそんな感じ

**デフォルトの名無しさん** · 2020/03/15(日) 14:28:52.20

アプリ制作専用言語という認識で差し支えないってことね

**デフォルトの名無しさん** · 2020/03/15(日) 14:45:30.20

2年前くらいの頃はサーバーサイドJavaも食いそうな勢いだったんだけど、見る影もないね
もうAndroidアプリ制作専用言語以上は何も期待できない

**デフォルトの名無しさん** · 2020/03/15(日) 14:57:29.36

何度も言われてるがベターJavaで、近代Java案件の置き換えが可能なのだが、
新規Java案件が今はもうAndroid非ゲームアプリくらいしかないため、結局Android非ゲームアプリくらいしか用途がない
もちろんかつてのJavaのように何を作っても構わないしなんでもだいたい作れるが、そもそもわざわざJavaで作る理由がもうないので…

**デフォルトの名無しさん** · 2020/03/15(日) 15:54:52.18

う、うん…

**デフォルトの名無しさん** · 2020/03/15(日) 19:04:24.46

javaの上位互換だからjava出来るならKotlinも直ぐ出来るって勘違いしてる人結構いるけど、
細かいところで書き方とか違うからそれなりに慣れるまで時間かかるよね

**デフォルトの名無しさん** · 2020/03/15(日) 19:05:45.28

まぁ何でもそうじゃね

**デフォルトの名無しさん** · 2020/03/15(日) 19:14:18.96

( ´ﾟдﾟ｀)

**デフォルトの名無しさん** · 2020/03/15(日) 19:24:15.07

Javaはお固い分野でも新規に使われてるのに
縁がない人は頓珍漢な分析するよね

**デフォルトの名無しさん** · 2020/03/15(日) 19:57:21.56

Java＜kotlinだけどそもそも新規でのJava需要が下がってきてるから流行らないって事か？

**デフォルトの名無しさん** · 2020/03/15(日) 20:02:19.40

>>726
「新規に使われてる」の解釈が違う
文字通りの意味じゃない

**デフォルトの名無しさん** · 2020/03/15(日) 21:07:47.62

>>727
Java<Kotlinな業界ではサーバーサイドJVMは落ち目だね
世間一般には圧倒的にJava>Kotlin

**デフォルトの名無しさん** · 2020/03/16(月) 00:53:01.45

>>728
どういうこと？
否定をするなら解説込みで欲しい

**デフォルトの名無しさん** · 2020/03/17(火) 01:35:07.82

かつてJavaは凄く人気が有った言語だから、エコシステムが物凄く大きい。
一方、KotlinはAndroid開発で使う人は使うと言う位置づけなのでは。

**デフォルトの名無しさん** · 2020/03/17(火) 07:47:03.83

エンタープライズでJavaを採用するような案件や環境は安定と安心が最優先すぎるのが逆風だと思う
Kotlinで生産性が上がると言われても移行の総コスト、安いコーダーが安定供給できるか
この先立ち消えたりJBがやらかしたりでKotlinコードが不良資産化しないかなど不安が大きい
おじさんを説得するには実績が欲しいがまだキャズムを越えない
越えて欲しいなあ

**デフォルトの名無しさん** · 2020/03/17(火) 10:22:24.77

エンタープライズではテストと比べればコーディングの手間は無視できるし、
一発作り切ったら運用に移管して手を切るのが基本だからコードが冗長で見通しが悪いとかはあまり問題にならない
どう考えてもマイナー言語ロックインのリスクをペイしないよ

**デフォルトの名無しさん** · 2020/03/17(火) 14:06:05.53

KotlinはJavaとは宣言の書き方が前後逆になっただけの様な言語のイメージ。
それ以外でも何かは良くなっているかもしれないが、何かは悪くなっているだろうと予想され、敢えてJavaの代わりに使おうとは思えない。
KotlinはAndroidでは使えても、デスクトップでは難しいだろうが、
Javaなら、Swingを使えば、Win/Mac/Linuxで共通アプリが作れる。
昔はさらにここにブラウザ内のアプレットも加わっていたが、今はそれが動かなくなった。
ところが、アプレットをWasmとして復活させる動きも出ているようだから、プラットフォームは広い。
恐らくそのうちSwingもAndroidやiOSで動くようになるのではないか。

**デフォルトの名無しさん** · 2020/03/17(火) 14:21:17.83

なんで思い込みのイメージだけで語るの

**デフォルトの名無しさん** · 2020/03/17(火) 14:26:37.12

>>733
短い簡単なプログラムなら、習いたての新しい言語でも作れるが、長くて複雑なプログラムには、十分に時間をかけて習熟した言語でないと作るのは難しい。
次々に生まれる新しい言語をニワカに学んでもいいプログラムを作るのは難しいのだ。
新しい言語では逆に間違ってしまったり、やりたいことを実現する方法が分からなくてそれを調べるために効率が下がることが多い。
Javaの言語仕様は、人気が有ったことからも分かるように昔から既に優れており、それはそれで一つの完成系をなしている。
根本的に新しい言語は一部だけは優れていても、どこかではむしろ劣っていることが多い。
一方でJavaはJavaで進化し続けている。

**デフォルトの名無しさん** · 2020/03/17(火) 15:01:46.47

だからなに？

**デフォルトの名無しさん** · 2020/03/17(火) 15:04:23.46

だから勉強したくないでござる

**デフォルトの名無しさん** · 2020/03/17(火) 15:07:56.32

そういうことなんだろな。
JAVAだけやっとけば安心なんだ！って自分に言い聞かせてるようにしか見えん

**デフォルトの名無しさん** · 2020/03/17(火) 15:52:42.79

言語ばかり学んでいてもな。

**デフォルトの名無しさん** · 2020/03/17(火) 15:56:41.70

>>739
そういう観点でいえば、学ぶべきはKotlinじゃなくてGoやC#などの非JVM系言語だろう
Kotlinを選んでいる時点で、自分もまたコンフォートゾーンに留まろうとしている平凡な人間の一員であることを自覚したほうがいいぞ

**デフォルトの名無しさん** · 2020/03/17(火) 16:00:09.84

どんなに優秀な人でも、あらゆる言語やツールキットを学ぶほどの時間は無いから、学ぶべきものを取捨選択や優先順位付けが重要。
一つの言語だけを学んで、プログラムに必要ななんらかの(専門的な)知識を学ぶのも立派な選択だ。

**デフォルトの名無しさん** · 2020/03/17(火) 16:05:41.43

令和のstaticおじさん(この方はJavaおじさん)かな

**デフォルトの名無しさん** · 2020/03/17(火) 16:29:11.06

ねぇねぇScalaって息してる？Kotlinとどっちがすごい？

**デフォルトの名無しさん** · 2020/03/17(火) 16:45:02.15

息はしているがどっちが凄いかは知らん

ScalaのコードをJavaScriptのコードに変換する「Scala.js 1.0」リリース
https://thinkit.co.jp/news/bn/17374

**デフォルトの名無しさん** · 2020/03/17(火) 16:46:06.62

>>743
何でも学べばよいと言うわけではない。
優先順位を付けられない人は非効率。

**デフォルトの名無しさん** · 2020/03/17(火) 16:49:51.14

>>746
というか、新しい言語を学んで無い人を馬鹿にするのは良くない。
自然法則は昔からずっと変化しないから学んで損は無いが、言語は人工的なため、不変性も無く学ぶ価値の無いものも多数含まれる。
その取捨選択が重要。

**デフォルトの名無しさん** · 2020/03/17(火) 17:07:25.05

少なくとも多言語のスレでJAVAだけでいいんだ！って力説されてもね

**デフォルトの名無しさん** · 2020/03/17(火) 17:07:39.27

他言語

**デフォルトの名無しさん** · 2020/03/17(火) 17:09:29.69

Kotlinが蔓延することで困る人もいるんだから。

**デフォルトの名無しさん** · 2020/03/17(火) 17:13:44.67

毎日使うものだから。

**デフォルトの名無しさん** · 2020/03/17(火) 17:17:56.69

>>748
ネットではKotlinそのものに価値があるようなことを言う人を良く見かけるが、実際はGoogleがOracleとの訴訟に負けて、Javaを使っていることを注意されて、それで使われるようになっただけの言語、と捉えるのが標準見解だ。

**デフォルトの名無しさん** · 2020/03/17(火) 17:27:30.89

>>734
> Javaなら、Swingを使えば、Win/Mac/Linuxで共通アプリが作れる。

Javaのライブラリ使うならKotlinでもできることになるが？

**デフォルトの名無しさん** · 2020/03/17(火) 17:31:48.86

>>736
わかった。それじゃあかれこれ30年ぐらい使い続けているPerlと35年ぐらい使い続けているC言語を使うことにするよ。Javaのような新言語に手を出すのは止めておこう。

**デフォルトの名無しさん** · 2020/03/17(火) 18:15:43.46

>>754
別にそれでいいんじゃない。
俺はJavaの回し者でもなんでもないからな。

**デフォルトの名無しさん** · 2020/03/17(火) 19:06:22.80

>>736
そういう観点なら、better javaのkotlinを学習する費用対効果は大きい。

実際、自分でクラスを設計するのならnull freeにできるkotlinの価値は高い。

……というより、型無しのnullを排除できないjavaの型システムが破綻しているだけだけどな。いいかげん、nullを受け付けないクラス／変数に対応してほしいぜ。

**デフォルトの名無しさん** · 2020/03/17(火) 19:15:03.66

>>756
むしろ、null を使うことは美しいと思っている。
引数にnullを渡すかどうかで動作を変えられることは、プログラミングの中でも最もスマートな方法。

**デフォルトの名無しさん** · 2020/03/17(火) 19:30:31.89

でも、いざnull safetyの言語使ってみると!!演算子使う自分のコードが気になって負けた気になる

**デフォルトの名無しさん** · 2020/03/17(火) 19:33:21.73

!!は便利だけど後で見返すと消したくなるわ
見てて綺麗じゃない

**デフォルトの名無しさん** · 2020/03/17(火) 20:14:28.04

それ
見てて気になるし負の感情がわくw

**デフォルトの名無しさん** · 2020/03/17(火) 23:29:23.16

>>756
JDK25ぐらいでなんとかならんのかな

**デフォルトの名無しさん** · 2020/03/17(火) 23:54:31.16

kotlin勉強に有効な書籍はなんだ？

**デフォルトの名無しさん** · 2020/03/18(水) 00:01:29.88

Javaできるならサンプル見ただけでなんとなく使える
本読まなきゃいけないような奴が手を出す言語ではない

**デフォルトの名無しさん** · 2020/03/18(水) 00:33:22.47

当然、Kotlin の会長である太郎本！

Kotlinスタートブック -新しいAndroidプログラミング、長澤太郎、2016

**デフォルトの名無しさん** · 2020/03/18(水) 00:35:21.26

>>763
本読まなきゃいけない奴が手を出す言語ではない(ドヤァ)
キモすぎアホすぎて草
んなこと誰も聞いてねえってのw
質問に答えてやれよカス
そもそも仕事だったら新規言語に手を出す出さないは個人の判断関係なく強いられることもあるだろうw
それともニートか？お前w

>>762
完全初心者なら>>273-275あたりで出てる本がいいんじゃないかな

**デフォルトの名無しさん** · 2020/03/18(水) 00:37:04.70

>>763
サンプルコピペして使えた気になってるコピペプログラマーの典型みたいなこと言っててワロタ

**デフォルトの名無しさん** · 2020/03/18(水) 03:25:07.07

有名な雑食系エンジニア・KENTA も、YouTube で言ってたけど、
Scala が廃れた理由は、初心者にマウント取って、悦に入る人が多いからw

JVM 系は土方だから、土木業と同じ産業構造、多重請負・奴隷構造を持つから、
奴隷は初心者に対して、マウントを取らざるを得ないw

Ruby が、なぜナイスなのか、Cookpad などの自社サービス系だから。
多重請負・奴隷構造じゃないから

JVM 系は高学歴総合職・ノンプログラマーが、
低学歴奴隷・IT 土方を使って、もうける商売だから

だから、勧める人が少ない

**デフォルトの名無しさん** · 2020/03/18(水) 07:13:52.23

>>767
言語外の仕様か。いくらか眉唾だが興味深い。

**767** · 2020/03/18(水) 08:26:52.48

雑食系エンジニア・KENTA

Scalaが日本で衰退し始めている理由を説明します
https://www.youtube.com/watch?v=kFzLia7YZQU

**デフォルトの名無しさん** · 2020/03/18(水) 08:41:22.06

動画で食ってる奴がエンジニアを名乗る不思議な世の中

**デフォルトの名無しさん** · 2020/03/18(水) 12:35:47.10

>>767-769
なるほど
KENTAはクソだけど内容は腑に落ちる部分があるな

**デフォルトの名無しさん** · 2020/03/18(水) 13:23:33.04

>>757
Kotlinでそのようにしたければそのように書けば良い。できないわけではない。使い分けできて尚且つコンパイル時のチェックが厳しいだけ。

**デフォルトの名無しさん** · 2020/03/18(水) 14:41:11.55

昨日は変なおじさんが暴れてたなあ

**デフォルトの名無しさん** · 2020/03/18(水) 21:03:27.37

>>769
3行でまとめろ

**デフォルトの名無しさん** · 2020/03/18(水) 21:05:09.86

ここの人はjavaを触る前にkotlin触った人いる？

**767** · 2020/03/19(木) 03:59:43.72

要するに、複雑なものは習得コストが高いから、暇人しか集まらないようになる。
暇人は、初心者に参入されると食えなくなるから、マウント取って邪魔してくる

防衛省・原発みたいなものと同じ。
誰にも分からないから、チェック体制も構築できなくなる

誰にも何をやっているのか、さっぱり分からないけど、
上層部は高い給料をもらえる体制。
その体制を維持していくことが目的になっている

複雑なものには、真実ではないダマシが入ってくる。
人々を煙に巻く。それがガン

逆に、簡単なRuby には、嘘が付け入る隙がないから、誰もだませない。
これが本当のオープン。
ブロックチェーンみたいなもの。支配者が国民をだませない

**デフォルトの名無しさん** · 2020/03/19(木) 05:48:04.13

>>776
長くなったのに>>767の最初の2行しか説明できてない。残念。
KENTAがRuby推しということはわかった。

**デフォルトの名無しさん** · 2020/03/19(木) 07:39:11.58

>>775

>>709

**デフォルトの名無しさん** · 2020/03/19(木) 12:38:32.21

>>757
型自体の操作(メタプログラミングとか)ならともかく、まずはクラスの中での操作を考えるべき。多態とかnull objectとか。

javaで一番多いトラブルはヌルポだろ。本来なら真っ先に対策すべきだと思うがね。

**デフォルトの名無しさん** · 2020/03/19(木) 12:52:07.67

kentaってイケダハヤトみたいになってきたな

**デフォルトの名無しさん** · 2020/03/19(木) 15:15:37.74

>>779
C++ で言えばたったこんな程度のこと。
NULLの処理なんて難しくもなんとも無い。

CWnd *MyCreateWindow(const char *pszTitle);　　//プロトタイプ宣言

// 使い方の例:
MyCreateWindow(NULL); // タイトル無しでWindow作成
MyCreateWindow("タイトル文字列"); // タイトル有りでWindow作成

// 関数定義:
CWnd *MyCreateWindow(const char *pszTitle)
{
　if ( pszTitle == NULL ) {
　　(タイトルが無いとして処理);
　}
　else {
　　(タイトルが有るとして処理);
　}
}

**デフォルトの名無しさん** · 2020/03/19(木) 17:10:21.28

なんで頓珍漢な流れになってるんだ
nullを安全に扱える言語なのにKotlin未経験者多すぎだろこのスレ

**デフォルトの名無しさん** · 2020/03/19(木) 17:16:34.26

荒らし目的のJAVAコーダーしかおらんやろ

**デフォルトの名無しさん** · 2020/03/19(木) 18:04:34.63

ことりん

**デフォルトの名無しさん** · 2020/03/19(木) 18:22:01.77

それnullでやる必要あるの？

**デフォルトの名無しさん** · 2020/03/19(木) 19:39:51.06

言語進化の歴史なんてまるで知らんのだろうな

**デフォルトの名無しさん** · 2020/03/19(木) 20:12:45.87

知る必要あるの？

**デフォルトの名無しさん** · 2020/03/19(木) 20:16:42.34

考えてみると、ない

**デフォルトの名無しさん** · 2020/03/19(木) 20:20:50.17

ネットでドヤ顔したりマウント取ったりするには有用な知識

**デフォルトの名無しさん** · 2020/03/19(木) 21:17:12.88

>>785
特殊な場合があるときにそれを-1とかで表すよりも100億倍まし
特殊な場合がないのにnullableにするのは論外
何も考えず!!演算子を使うのも論外
NullObjectを作るかどうかはメリットデメリットあるのでケースバイケース
脳死で作るのはJavaでenumを使わずにTypesafe enumパターンを手書きするような冗長さになることもあるし
下手に使うと-1と同じ弱点を埋め込む場合もある

nullに忌避感がある人はこのスレをnullで検索すると議論が参考になるかもしれない

**デフォルトの名無しさん** · 2020/03/19(木) 22:46:33.35

>>757 はKotlinを否定してJavaでnullを扱いたいのか、KotlinのT?型と?.演算子や?:演算子を奨励したいのか
読んでいてよく分からなくなってきた。

**デフォルトの名無しさん** · 2020/03/19(木) 22:48:27.28

>>790
少なくとも>>781の内容はnullでやる必要ないよね？って話なんだけど？
あれは特殊な場合なの？

**デフォルトの名無しさん** · 2020/03/20(金) 01:28:48.16

>>792
少し例が悪かったので変えてみる:

CWnd *MyCreateWindow(CWnd *pParent);　　//プロトタイプ宣言

// 使い方の例:
MyCreateWindow(NULL); // 親の無いWindowを作成。自分が最上位Windowとなる。
MyCreateWindow(親Window); // 指定したWindowの子WindowとしてWindowを作成

// 関数定義:
CWnd *MyCreateWindow(CWnd *pParent)
{
　if ( pParent == NULL ) {
　　(親が存在しない最上位Windowを新規作成);
　}
　else {
　　(pParentの子Windowを新規作成);
　}
}

**デフォルトの名無しさん** · 2020/03/20(金) 01:34:03.99

>>793
もし、NULLを使いたくないのなら次のようにするしかないことになり、2つの引数に分かれてしまいむしろ危険性が増すばかりでなく、親が存在しない場合にはダミーのWindowのアドレスを指定しなければならなくなる:
CWnd *MyCreateWindow(CWnd *pParent, BOOL bChild);　　//プロトタイプ宣言

// 使い方の例:
MyCreateWindow(ダミーのWindow, FALSE); // 親の無いWindowを作成。自分が最上位Windowとなる。
MyCreateWindow(親Window, TRUE); // 指定したWindowの子WindowとしてWindowを作成

// 関数定義:
CWnd *MyCreateWindow(CWnd *pParent, BOOL bChild)
{
　if ( !bChild ) {
　　(親が存在しない最上位Windowを新規作成);
　}
　else {
　　(pParentの子Windowを新規作成);
　}
}

**デフォルトの名無しさん** · 2020/03/20(金) 01:38:28.40

>>794
メソッドを引数なしと親ウィンドウ指定ありの2種類にオーバーロードすればいいね
オーバーロードできない言語でも名前を分かりやすいように分ければいい
この場合はnullは使わない方がベター

**デフォルトの名無しさん** · 2020/03/20(金) 01:41:51.33

>>794
現実には、「ダミーのWindow(のアドレス)」なんてものは作りえないかもしれない。
だとすれば、NULLを使わずにこれらの事を行いたいなら次のように、関数を2つに分けるしかなくなってしまうかもしれない。
しかしそれは間違いが入り込みやすい良く無いプログラムである:

CWnd *MyCreateTopWindow();　　　　　　　　//親の無いWindowを作成する関数。
CWnd *MyCreateChildindow(CWnd *pParent);　//pParentの子Windowを作成する関数。

// 使い方の例:
MyCreateTopWindow(); // 親の無いWindowを作成。自分が最上位Windowとなる。
MyCreateChildWindow(親Window); // 指定したWindowの子WindowとしてWindowを作成

**デフォルトの名無しさん** · 2020/03/20(金) 01:45:38.48

>>795
似たような処理を行う関数は、完全に2つに分けてしまうとバグの原因になる。
理由は、内部で似た処理を行っている箇所を両方とも修正する必要が出て来やすくなり、一方だけ修正して他方は修正し忘れたりすることが多くなるから。
こまごまとした違いが有って、一致している部分もあったりするので、単純な機械比較は出来ないので同一性チェックを人間の目で行わなければならなくなる。
だから、>>793のように書いたほうがずっと安全になる。

**デフォルトの名無しさん** · 2020/03/20(金) 01:48:47.36

>>797
「親が有るかどうか」
という一つのパラメータだけなら、まだ良いが、
「メニューオブジェクトを渡すか渡さないかでメニューが付くかどうか分ける」
なども付いたりすれば、組み合わせ爆発が起きるため、関数を完全に分けてしまうのは非常に非効率で危険なプログラミングとなる。

**デフォルトの名無しさん** · 2020/03/20(金) 01:52:10.51

共通化が必要ならNullObjectの多態でも関数型でも使えばいいよ

C言語時代からアップデートされてない知識でモダン言語でのプラクティスを説こうとしているのが謎だよ
タイムスリップしたお侍が自衛隊に兵法を指南するような冗談だよ

**デフォルトの名無しさん** · 2020/03/20(金) 01:56:11.47

組み合わせ爆発についてはデフォルト引数使えばよろし

**デフォルトの名無しさん** · 2020/03/20(金) 01:59:36.15

>>800
そのデフォルト引数には、NULLかNullObjectを指定するしかないはず。
なんで、NULLで済むのにNullObjectを使うの。
それで安全になるのか？

**デフォルトの名無しさん** · 2020/03/20(金) 02:03:02.63

>>799
では、>>793の例を NullObjectや多態を使って分かり易くて安全に書き直してみてください。

**デフォルトの名無しさん** · 2020/03/20(金) 02:49:45.65

>>796
すべてのウインドウはRootWindow配下とするみたいなルールを設定して、親のないウインドウは禁止するればいい。

linuxのプロセスが必ずinit配下になるのと同じ感じ。

**デフォルトの名無しさん** · 2020/03/20(金) 02:54:28.27

>>803
それは可能だけど、グラフィックのFrameBufferの容量が大きいので、
デスクトップに浮いているWindowの場合にChildWindowと同じ処理をしたのでは
メモリーの無駄使いになることがあったり、
デスクトップに浮いているWindowとChildWindowとでは動作がかなり違っていたり
することが多いので初期化段階から if 文で場合分けしないと無理が有る事が多い。

だから、そのような「統一した考え」では結局は、効率が下がるために
実際には駄目プログラムとなる。

**デフォルトの名無しさん** · 2020/03/20(金) 03:01:28.97

>>804
さらに付け加えるなら、RootWindow のオブジェクトの名前を「覚えるのが面倒」
だったり、打ち込むのが長くなって大変と言う事情もある。
例えば、Windowの場合には、「DesktopWindow」という名前で、
Menuオブジェクトが無い場合には、「MenuNull」みたいな名前となる。
しかし実際にはこんな簡単な名前で無い事が多いので、マニュアルをいちいち調べ
直す手間がいる。
一方、NULLだといろんな場面全てNULLなので、覚えることが少なくて済むし、
打ち込むにも4文字で済むので楽。
関数を呼び出す際も短いので一行で書ける場合が多くなり、見易い。

**デフォルトの名無しさん** · 2020/03/20(金) 05:05:17.32

>>793
Kotlin ならこんな風にすれば良いんじゃないの?

fun myCreateWindow(parent: CWnd? = null): CWnd = if (parent == null) 親なし上位Window作成 else parentの子Window作成

nullable がどうしても嫌ならこうするか。

fun myCreateWindow(parent: CWnd = 親なし上位Window): CWnd = if (parent != 親なし上位Window) parentの子Window作成 else parent

**デフォルトの名無しさん** · 2020/03/20(金) 06:32:14.26

言語やベンチマークの議論一般にいえることだけど、自分の有利な土俵に引っ張りこめば何とでも主張できる。

Kotlinは>>805向けには作られていない。というだけのこと。

**デフォルトの名無しさん** · 2020/03/20(金) 06:53:01.35

>>804
そこはクラス分けてポリモーフィズムで上手くやろうよ

先のウインドウタイトルといい、例が良くないんでは？

**デフォルトの名無しさん** · 2020/03/20(金) 07:53:37.14

>>801
書かれてたサンプルコードでは真っ先に分岐が入ってたから「この場合は」オーバーロードかメソッド分割がベターと回答した
後付けされた条件を加味するなら>>806のnullable型がいい
privateな処理内で局所的にnullabeを使うことに異論はない
Kotlinならヌルポが出ないから安全

覚えるのが面倒ということまで気にする公開APIなら親にnullを指定すると親無しになるというルールを覚えさせるよりも
親の引数を省略可能にするかメソッド名を用途別に分けてクラス内で処理を共通化した方が使いやすい

nullは単一なので楽という話は、nullは単一なのでいろんな意味がまぜこぜに使われ区別できないという裏返しでもある
variantは型がないので楽、グローバル変数は楽、staticは楽というのに通じる

**デフォルトの名無しさん** · 2020/03/20(金) 07:58:22.42

メソッド引数にnullを与えたときヌルポが出るのかトップレベルウィンドウになるのかドキュメントを読まないと判別できない公開APIは残念
省略時デフォルトとして内部的に使うのとはまた違う

**デフォルトの名無しさん** · 2020/03/20(金) 09:18:27.10

Kotlin では、プログラマーが自分で、null を判断したら、ダメ！
null チェックを書かない人がいるから、バグが残る

C++ で言えば、スマートポインターみたいなものを使って、
自動的に判断するのが正しい

どこかで、nullチェックをして、nullじゃなければ、
null許容型を使わないように書く

**デフォルトの名無しさん** · 2020/03/20(金) 10:12:13.96

>>811
だったらそもそも静的な型がない上に基本的にプログラマが明示的な型チェックもしないことが普通なRubyは、
Kotlinで常にnull許容でチェックも一切しない以上に遥かにバグが残るってことになる(実際そう)なのだが、
自分で意味分かって言ってんのかなこいつ