Kotlin 6

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2019/06/22(土) 15:59:57.23ID:zj+KJbMh
JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう

※前スレ
Kotlin 5
https://mevius.5ch.net/test/read.cgi/tech/1544268581/
2020/03/17(火) 19:30:31.89ID:s3acJuhP
でも、いざnull safetyの言語使ってみると!!演算子使う自分のコードが気になって負けた気になる
2020/03/17(火) 19:33:21.73ID:3WRfeEJw
!!は便利だけど後で見返すと消したくなるわ
見てて綺麗じゃない
2020/03/17(火) 20:14:28.04ID:s3acJuhP
それ
見てて気になるし負の感情がわくw
2020/03/17(火) 23:29:23.16ID:I7Fcdy1u
>>756
JDK25ぐらいでなんとかならんのかな
2020/03/17(火) 23:54:31.16ID:Whb0iFr7
kotlin勉強に有効な書籍はなんだ？
2020/03/18(水) 00:01:29.88ID:rB/x/s49
Javaできるならサンプル見ただけでなんとなく使える
本読まなきゃいけないような奴が手を出す言語ではない
2020/03/18(水) 00:33:22.47ID:LQtyodHE
当然、Kotlin の会長である太郎本！

Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016
2020/03/18(水) 00:35:21.26ID:qIM0w55M
>>763
本読まなきゃいけない奴が手を出す言語ではない(ドヤァ)
キモすぎアホすぎて草
んなこと誰も聞いてねえってのw
質問に答えてやれよカス
そもそも仕事だったら新規言語に手を出す出さないは個人の判断関係なく強いられることもあるだろうw
それともニートか？お前w


>>762
完全初心者なら>>273-275あたりで出てる本がいいんじゃないかな
2020/03/18(水) 00:37:04.70ID:JGfgRlCq
>>763
サンプルコピペして使えた気になってるコピペプログラマーの典型みたいなこと言っててワロタ
2020/03/18(水) 03:25:07.07ID:LQtyodHE
有名な雑食系エンジニア・KENTA も、YouTube で言ってたけど、
Scala が廃れた理由は、初心者にマウント取って、悦に入る人が多いからw

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

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

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

だから、勧める人が少ない
2020/03/18(水) 07:13:52.23ID:yDvvdBVq
>>767
言語外の仕様か。いくらか眉唾だが興味深い。
769767
垢版 |
2020/03/18(水) 08:26:52.48ID:LQtyodHE
雑食系エンジニア・KENTA

Scalaが日本で衰退し始めている理由を説明します
https://www.youtube.com/watch?v=kFzLia7YZQU
2020/03/18(水) 08:41:22.06ID:iE2DLaXa
動画で食ってる奴がエンジニアを名乗る不思議な世の中
771デフォルトの名無しさん
垢版 |
2020/03/18(水) 12:35:47.10ID:fwLKdVFo
>>767-769
なるほど
KENTAはクソだけど内容は腑に落ちる部分があるな
772デフォルトの名無しさん
垢版 |
2020/03/18(水) 13:23:33.04ID:B9Jc5Lrr
>>757
Kotlinでそのようにしたければそのように書けば良い。できないわけではない。使い分けできて尚且つコンパイル時のチェックが厳しいだけ。
2020/03/18(水) 14:41:11.55ID:QhEd5Nre
昨日は変なおじさんが暴れてたなあ
2020/03/18(水) 21:03:27.37ID:dhpxSw9T
>>769
3行でまとめろ
2020/03/18(水) 21:05:09.86ID:qIM0w55M
ここの人はjavaを触る前にkotlin触った人いる？
776767
垢版 |
2020/03/19(木) 03:59:43.72ID:JDU05jIv
要するに、複雑なものは習得コストが高いから、暇人しか集まらないようになる。
暇人は、初心者に参入されると食えなくなるから、マウント取って邪魔してくる

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

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

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

逆に、簡単なRuby には、嘘が付け入る隙がないから、誰もだませない。
これが本当のオープン。
ブロックチェーンみたいなもの。支配者が国民をだませない
2020/03/19(木) 05:48:04.13ID:z/hUxg19
>>776
長くなったのに>>767の最初の2行しか説明できてない。残念。
KENTAがRuby推しということはわかった。
2020/03/19(木) 07:39:11.58ID:urEXhT7g
>>775

>>709
2020/03/19(木) 12:38:32.21ID:3l1mva9i
>>757
型自体の操作(メタプログラミングとか)ならともかく、まずはクラスの中での操作を考えるべき。多態とかnull objectとか。

javaで一番多いトラブルはヌルポだろ。本来なら真っ先に対策すべきだと思うがね。
2020/03/19(木) 12:52:07.67ID:yzbbR7me
kentaってイケダハヤトみたいになってきたな
781デフォルトの名無しさん
垢版 |
2020/03/19(木) 15:15:37.74ID:VRFqiqhe
>>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.28ID:rBTxc+YZ
なんで頓珍漢な流れになってるんだ
nullを安全に扱える言語なのにKotlin未経験者多すぎだろこのスレ
2020/03/19(木) 17:16:34.26ID:/JEYrZ/n
荒らし目的のJAVAコーダーしかおらんやろ
2020/03/19(木) 18:04:34.63ID:j3UhLeRz
ことりん
2020/03/19(木) 18:22:01.77ID:TkZTFqNu
それnullでやる必要あるの？
2020/03/19(木) 19:39:51.06ID:YRL0u/U8
言語進化の歴史なんてまるで知らんのだろうな
2020/03/19(木) 20:12:45.87ID:jEN69kGO
知る必要あるの？
2020/03/19(木) 20:16:42.34ID:Pzb6grX0
考えてみると、ない
2020/03/19(木) 20:20:50.17ID:XcKebLm1
ネットでドヤ顔したりマウント取ったりするには有用な知識
2020/03/19(木) 21:17:12.88ID:rBTxc+YZ
>>785
特殊な場合があるときにそれを-1とかで表すよりも100億倍まし
特殊な場合がないのにnullableにするのは論外
何も考えず!!演算子を使うのも論外
NullObjectを作るかどうかはメリットデメリットあるのでケースバイケース
脳死で作るのはJavaでenumを使わずにTypesafe enumパターンを手書きするような冗長さになることもあるし
下手に使うと-1と同じ弱点を埋め込む場合もある

nullに忌避感がある人はこのスレをnullで検索すると議論が参考になるかもしれない
2020/03/19(木) 22:46:33.35ID:z/hUxg19
>>757 はKotlinを否定してJavaでnullを扱いたいのか、KotlinのT?型と?.演算子や?:演算子を奨励したいのか
読んでいてよく分からなくなってきた。
2020/03/19(木) 22:48:27.28ID:TkZTFqNu
>>790
少なくとも>>781の内容はnullでやる必要ないよね？って話なんだけど？
あれは特殊な場合なの？
2020/03/20(金) 01:28:48.16ID:405ti7Ej
>>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.99ID:405ti7Ej
>>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.40ID:i2c+AgK7
>>794
メソッドを引数なしと親ウィンドウ指定ありの2種類にオーバーロードすればいいね
オーバーロードできない言語でも名前を分かりやすいように分ければいい
この場合はnullは使わない方がベター
2020/03/20(金) 01:41:51.33ID:405ti7Ej
>>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.48ID:405ti7Ej
>>795
似たような処理を行う関数は、完全に2つに分けてしまうとバグの原因になる。
理由は、内部で似た処理を行っている箇所を両方とも修正する必要が出て来やすくなり、一方だけ修正して他方は修正し忘れたりすることが多くなるから。
こまごまとした違いが有って、一致している部分もあったりするので、単純な機械比較は出来ないので同一性チェックを人間の目で行わなければならなくなる。
だから、>>793のように書いたほうがずっと安全になる。
2020/03/20(金) 01:48:47.36ID:405ti7Ej
>>797
「親が有るかどうか」
という一つのパラメータだけなら、まだ良いが、
「メニューオブジェクトを渡すか渡さないかでメニューが付くかどうか分ける」
なども付いたりすれば、組み合わせ爆発が起きるため、関数を完全に分けてしまうのは非常に非効率で危険なプログラミングとなる。
2020/03/20(金) 01:52:10.51ID:i2c+AgK7
共通化が必要ならNullObjectの多態でも関数型でも使えばいいよ

C言語時代からアップデートされてない知識でモダン言語でのプラクティスを説こうとしているのが謎だよ
タイムスリップしたお侍が自衛隊に兵法を指南するような冗談だよ
2020/03/20(金) 01:56:11.47ID:i2c+AgK7
組み合わせ爆発についてはデフォルト引数使えばよろし
2020/03/20(金) 01:59:36.15ID:405ti7Ej
>>800
そのデフォルト引数には、NULLかNullObjectを指定するしかないはず。
なんで、NULLで済むのにNullObjectを使うの。
それで安全になるのか？
2020/03/20(金) 02:03:02.63ID:405ti7Ej
>>799
では、>>793の例を NullObjectや多態を使って分かり易くて安全に書き直してみてください。
2020/03/20(金) 02:49:45.65ID:4pMtFWMQ
>>796
すべてのウインドウはRootWindow配下とするみたいなルールを設定して、親のないウインドウは禁止するればいい。

linuxのプロセスが必ずinit配下になるのと同じ感じ。
2020/03/20(金) 02:54:28.27ID:405ti7Ej
>>803
それは可能だけど、グラフィックのFrameBufferの容量が大きいので、
デスクトップに浮いているWindowの場合にChildWindowと同じ処理をしたのでは
メモリーの無駄使いになることがあったり、
デスクトップに浮いているWindowとChildWindowとでは動作がかなり違っていたり
することが多いので初期化段階から if 文で場合分けしないと無理が有る事が多い。

だから、そのような「統一した考え」では結局は、効率が下がるために
実際には駄目プログラムとなる。
2020/03/20(金) 03:01:28.97ID:405ti7Ej
>>804
さらに付け加えるなら、RootWindow のオブジェクトの名前を「覚えるのが面倒」
だったり、打ち込むのが長くなって大変と言う事情もある。
例えば、Windowの場合には、「DesktopWindow」という名前で、
Menuオブジェクトが無い場合には、「MenuNull」みたいな名前となる。
しかし実際にはこんな簡単な名前で無い事が多いので、マニュアルをいちいち調べ
直す手間がいる。
一方、NULLだといろんな場面全てNULLなので、覚えることが少なくて済むし、
打ち込むにも4文字で済むので楽。
関数を呼び出す際も短いので一行で書ける場合が多くなり、見易い。
806デフォルトの名無しさん
垢版 |
2020/03/20(金) 05:05:17.32ID:Edy1QoAW
>>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.26ID:Oo7Eeggj
言語やベンチマークの議論一般にいえることだけど、自分の有利な土俵に引っ張りこめば何とでも主張できる。

Kotlinは>>805向けには作られていない。というだけのこと。
2020/03/20(金) 06:53:01.35ID:4pMtFWMQ
>>804
そこはクラス分けてポリモーフィズムで上手くやろうよ

先のウインドウタイトルといい、例が良くないんでは？
2020/03/20(金) 07:53:37.14ID:i2c+AgK7
>>801
書かれてたサンプルコードでは真っ先に分岐が入ってたから「この場合は」オーバーロードかメソッド分割がベターと回答した
後付けされた条件を加味するなら>>806のnullable型がいい
privateな処理内で局所的にnullabeを使うことに異論はない
Kotlinならヌルポが出ないから安全

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

nullは単一なので楽という話は、nullは単一なのでいろんな意味がまぜこぜに使われ区別できないという裏返しでもある
variantは型がないので楽、グローバル変数は楽、staticは楽というのに通じる
2020/03/20(金) 07:58:22.42ID:i2c+AgK7
メソッド引数にnullを与えたときヌルポが出るのかトップレベルウィンドウになるのかドキュメントを読まないと判別できない公開APIは残念
省略時デフォルトとして内部的に使うのとはまた違う
2020/03/20(金) 09:18:27.10ID:CQQp7Y75
Kotlin では、プログラマーが自分で、null を判断したら、ダメ！
null チェックを書かない人がいるから、バグが残る

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

どこかで、nullチェックをして、nullじゃなければ、
null許容型を使わないように書く
2020/03/20(金) 10:12:13.96ID:1hj/B9bx
>>811
だったらそもそも静的な型がない上に基本的にプログラマが明示的な型チェックもしないことが普通なRubyは、
Kotlinで常にnull許容でチェックも一切しない以上に遥かにバグが残るってことになる(実際そう)なのだが、
自分で意味分かって言ってんのかなこいつ
2020/03/20(金) 10:31:11.84ID:EaZGEhh2
「真っ先に条件分岐が入ってたから」

はどこいったんだろう
適当やな..
2020/03/20(金) 10:38:58.93ID:EaZGEhh2
それにそもそもオーバーロードかメソッド分割がベターとかいってるが、設定するメソッドじゃなくて現在設定されてる値を取得するメソッドまたはプロパティを追加するときはいったいどんな値返すんだ??

普通に元からnullでいいだろ
2020/03/20(金) 10:47:13.64ID:IqcuAu3D
>>814
nullable使わないなら異なる型を返すんだよ。nullable含め場合分けを型で強制することで不必要なバグが入り込む余地を無くすのがnull safetyな言語の流儀
2020/03/20(金) 11:02:35.25ID:EaZGEhh2
そういう他人をわざと変な方向に導こうとしてもひっかからんしつまらんから..
2020/03/20(金) 13:05:07.29ID:405ti7Ej
>>808
>そこはクラス分けてポリモーフィズムで上手くやろうよ
具体的にポリモーフィオズムでどうやれば分かり易く書き直せるか教えてください。
2020/03/20(金) 13:55:01.27ID:i2c+AgK7
>>813
どこ行ったの意味がわからない
どこに矛盾を感じたの？

>>814
俺はメリットデメリット考慮してnullableも含めて最適なものを選ぶのがいいと言ってるんだよ
前提が変わればnullableが簡潔で具合いいところもあるだろ
>>794のサンプルでnullabeを選ぶ理由ある？
2020/03/20(金) 14:01:35.66ID:i2c+AgK7
>>818
訂正
デフォルト引数の初期値をnullとして使うケースは良かった
理由は上で書いた通り
2020/03/20(金) 14:39:06.40ID:405ti7Ej
そもそも null はそんなに危険ではない。
そのまま使おうとすれば、Windowsの場合だと、Release版ですらほぼ100%一般保護例外が生じるからどこで問題がおきているかも分かるし。
2020/03/20(金) 14:40:27.30ID:405ti7Ej
nullが危険といっている人は、MMUを使ってない化石の様なOSでの経験に基づくものなのかな。
2020/03/20(金) 14:47:03.13ID:405ti7Ej
if で場合分けせずに、オブジェクトのclassの仮想関数で場合分けさせると言う考え方
は時々聞くが、それはすべてをオブジェクト指向に置き換えれば上手く行くと言う根拠
のない浅はかな考え方だ。
経験を積むとその思想は間違いであることが分かってくる。
2020/03/20(金) 15:49:29.05ID:i2c+AgK7
ページ違反が起きて特定に悩まされたのが昭和
一般保護例外なりヌルポなりの発生元ステップをテストで洗い出すのが平成
モダン言語ではコンパイル時に検出するので品質もコストも優位

老人は自らの成功体験に頼るので新しく良いものが現れても知識体系に取り入れることが難しく適材適所の選択ができない
2020/03/20(金) 16:01:15.37ID:5BxgCAjb
祝日になった途端荒れだした
2020/03/20(金) 16:45:35.12ID:3oKoD+ta
能無しJAVAコーダーが暴れてるんだろ
2020/03/20(金) 16:50:44.74ID:405ti7Ej
>>823
むしろ、OOPでやればなんでも上手く行くと思い込んでいる頭の固い馬鹿にしか思えんが。
2020/03/20(金) 17:03:18.75ID:lyFWLrjP
Javaカスイライラで草
プログラマのくせに新しいもの嫌いとか致命的にセンスないだろw
さっさとやめろよこの業界w
2020/03/20(金) 17:08:13.91ID:3oKoD+ta
>>827
ほとんどはコーダーやろ
2020/03/20(金) 17:12:54.71ID:405ti7Ej
新しくても駄目なものは駄目。
新しければいいと思うな。
若ければ年上に勝てると思うな。
2020/03/20(金) 18:03:14.01ID:NjO7svfB
老人とか関係ないな。
愚者は経験に学ぶ
それだけ
831デフォルトの名無しさん
垢版 |
2020/03/20(金) 18:18:29.68ID:405ti7Ej
おまえが愚者だ。
2020/03/20(金) 19:36:44.38ID:lyFWLrjP
>>828
今時厳密にコーダープログラマーをわけてる現場なんかないだろwクソ老害か？w
2020/03/20(金) 19:37:18.52ID:lyFWLrjP
>>829
老害イライラで草
顔真っ赤にしてる暇あったらkotlinの勉強しようなwww
2020/03/20(金) 19:46:41.44ID:405ti7Ej
>>833
Javaはブームとなるほど、当時としてはちょっと革新的な言語だった。
Kotlinは全然違う。
2020/03/20(金) 21:17:36.75ID:3oKoD+ta
>>832
君が派遣されてるドカタ現場ではそうなんだね
2020/03/20(金) 21:21:57.46ID:6BEgHG50
何でお前らすぐに不毛な煽りあい始めるんだ
2020/03/20(金) 21:26:00.38ID:UGdtYAWR
nullセーフもoopも嫌いならgoがオススメですよ
2020/03/20(金) 21:28:58.30ID:lyFWLrjP
>>835
君が派遣されてるクソ現場は下流しかやってないから律儀にフロントとバックでコーダープログラマー分けてるんだねw
普通上流の仕事してたらそんな底辺下流の扱いなんか厳密に分けてないよwwwww
勉強になったねえ w
2020/03/20(金) 21:50:19.69ID:Oo7Eeggj
>>829
年寄りだったのか。
若い頃に苦労して身につけたテクニックが、言語仕様でカバーされて誰でも実践できるようになって、
脅かされている自分のアイデンティティを守るために必死になっている、ってところかな。
2020/03/20(金) 23:35:23.46ID:405ti7Ej
>>839
この板に居るようなパンチカード(?)を語るようなほどの年寄りではない。
NullObjectでNULLを代用することが、
「言語仕様で誰でも実践できるようになって、自分のアイデンティティーが脅かされる」
に該当するとはとても思えない。
2020/03/21(土) 00:05:57.23ID:5V8tQPWW
パンチカード載せてる台車ひっくり返したら大変
2020/03/21(土) 06:24:08.00ID:JAKzE64M
>>840
> この板に居るようなパンチカード(?)を語るようなほどの年寄りではない。
この板にパンチカードなんて単語一度も出てきてないけど誰のこと?
パンチカード世代ではないにしても、NULLを駆使するのが美しいテクニックだった時代の年寄りなんでしょ?
相手の主張を反論しやすいように歪曲するのはやめた方がいいですよ。

>NullObjectでNULLを代用することが、
「NullObjectでNULLを代用すること」はKotlinの言語仕様でないから、
そのように受け取ったのなら、Kotlinのコンセプトを理解していないか、
相手の主張を反論しやすいように歪曲する癖があるかのどちらか。

>>840が対話の成立しない相手であることが証明されたので
>>840の回答には大変満足しております。ありがとうございました。
2020/03/21(土) 09:04:23.03ID:Nklv0DXu
なんだ、親無しWindow を、null にしただけか。
確かに、そういうAPI があるけど、マネしない方がよい

それって、0 でも空文字列でも、何でもよいわけでしょ。
そうい所に、nullを使うのはおかしい

nullは、ヌルポだけに限定すべき！
異なる意味で使ってはならない！

使い方を文章に書いた時にも、
引数がnullなら、親無しWindowになりますというのも、ちょっとおかしい

そういう用途には、デフォルト引数！
2020/03/21(土) 09:36:51.55ID:oUFNTFet
>>820
それどっちかというと Windows 独自の文化だと思う
たまに Windows 系の助っ人に行ってコンソールに例外出まくりなのみてビビるよ
2020/03/21(土) 09:44:12.11ID:JAKzE64M
>>843
nullは存在しないことを意味すると考えれば、あながち間違いでもないと思うし、
デフォルト引数を使うにしてもデフォルト値はNullObjectになるだろうし。

というのは置くとして>>842で述べたように>>840にこれ以上構わないほうがいいと思うんだが。
2020/03/21(土) 09:55:22.84ID:3uF/mjPQ
俺が老人という言葉を使ったのは実年齢のことではなく振る舞いだよ
Kotlinのコンセプトを理解してないどころか学ぶ気すらない
C++でサンプルを提示する辺りJavaを知っているかすら怪しい
自分のアイデンティティーを脅かされるという自覚はなく、わざわざ下らないものの詳細を学ばなくても俺には経験上わかるんだという老人特有の驕りが見える
全貌が見えてないから議論が噛み合わない

このスレにはnullは一切使わずにNullObjectを使うべきと主張する層とnullableは安全とする層と適材適所で使うという層がいて、この老人にとっては全員敵であり区別できないのだろう
NullObjectはJavaでは効果的なプラクティスだったけどKotlinではStateパターンのような役割でないとさほど輝かないと俺は思う
KotlinでNullObjectが常にnull(able)の良き代替になるなんて誰も提示できないはず
この老人がその一点に拘り他を無視する限りやっぱり俺は正しいんだと信じ続けるだろうな
2020/03/21(土) 10:05:31.48ID:SrebAl5K
若い衆はほんと何がいいたいんだかわからん
2020/03/21(土) 10:12:24.90ID:3uF/mjPQ
>>845
あながち間違いでないことと良いAPIであることには隔たりがあると思うよ
参考としてはJavaが提供しているライブラリにおいてnullを指定してくださいというメソッドよりもオーバーロードを提供しているメソッドの方が多い
ウィンドウの例だけでなく一般化して考えると、引数のデフォルト値として空の関数を与えて綺麗に書けるケースも多い
メソッドごとにnullを渡すべきなのか空の関数を渡すべきなのかNullObjectがあるのかを考えず、引数を省略するというシグネチャーで判別可能な一貫した利用ができるのは優れたメソッド設計だと思う
2020/03/21(土) 11:44:22.68ID:oUFNTFet
爺さんが引数に null 渡す例出したのに釣られちゃってるけど
Javaでも戻り値に null かオブジェクト返す API は普通にあるからね
これは NullObject か nullable に修正したい
850デフォルトの名無しさん
垢版 |
2020/03/21(土) 12:37:46.26ID:R4utYKoB
プログラマーの気持ち悪い部分をいい感じに体現してくれてる
ここであれこれ書いてもぬかに釘
noteかブログにでも書いておけ
2020/03/21(土) 14:00:49.01ID:txJMIm7g
なんでも古い古いと言っていれば、どんなに駄目でも新しい言語や若い人が有利になってしまう法則。
2020/03/22(日) 04:45:41.69ID:HvrypJyW
引数の個数や型だけが異なる「関数の多態性」を行うと、プログラムが間違い易くなる。
なぜなら型や引数の個数の書き間違いをコンパイラが報告してくれなくなることがあるから。
C/C++で型が導入されたのもそういう間違いをコンパイラに発見してもらうためも有ったが、それが働きにくくなってしまう。
853デフォルトの名無しさん
垢版 |
2020/03/22(日) 04:50:38.77ID:HvrypJyW
>>852
一つの関数名に引数の型や個数が異なる関数が10種類くらい多重定義されていたとする。
これを使ったプログラムする際には、マニュアルを見、関数名だけでなく引数も非常に正確に書かなくてはならなくなる。
型や引数の順序や個数などが僅かでも間違っていると、自分が思っていたのとは違う定義のものが呼び出されてしまうことになるが、それでも「合法」になってしまうのでコンパイラがエラーを出してくれない。
また、後から動作を調べようと思ってマニュアルを見たときにも、見間違いで間違った定義の部分の説明を読んでしまう現象が生じ易くなる。
2020/03/22(日) 04:56:18.54ID:HvrypJyW
>>853
func(1,2);
と書いたつもりで、タイプミスなどで
func(1,2,0);
と書いたとしよう。
func()が多重定義されていない場合なら、コンパイラがエラーを出してくれる。
ところが、func()が多重定義されてしまっている場合、たまたま、3つの整数引数の定義があった場合、自分の思ったのとはかなり違う動作の関数なのに、コンパイラが何もエラーを出してくれなくなってしまうことが有り得る。

それから、知らず知らずに「引数の自動型変換」機能が働いてしまうことが有り得る。
それと関数の多重定義の両方が組み合わされると、自分が思っていたのとはかなり
違う動作の関数が間違って呼び出されることになっていても、気づくことができない。
本当はどの関数が呼び出されているのかが分からず、どんなにチェックしても原因が分からない難しいバグが入ってしまうことになるかもしれない。
2020/03/22(日) 05:13:54.89ID:TNUWFKUe
あーウゼー
2020/03/22(日) 08:47:08.62ID:sfJQKmPV
技術的な話でスレが進むのは、過疎ってるよりは良いことだよ
ほぼ読んでないから内容は知らんけど
2020/03/22(日) 09:31:29.37ID:nwybfWiz
>>854
その話は、引数爆発は嫌だ、じゃあデフォルト引数使え、で解決してるだろ
さらに付け加えるなら名前付き引数も使え
そのあたりのCやJava時代の弱点をKotlinやC#は克服済みだ
あと多重定義は多態とは呼ばない
2020/03/22(日) 09:32:27.12ID:nwybfWiz
>>854
たまたま同じ型ばかりを引数にとる関数で順番を間違えるヒューマンエラーには配慮できるのに、nullを多用したときに誰かがミスして実行時エラーが多発するリスクに目を向けないのは何故？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況