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/
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を多用したときに誰かがミスして実行時エラーが多発するリスクに目を向けないのは何故？
2020/03/22(日) 09:58:58.91ID:CQOUf5Rv
>>857
>あと多重定義は多態とは呼ばない

異なる型に対する多重定義は多態の一種だよ
2020/03/22(日) 11:22:24.81ID:nwybfWiz
>>859
すまんアドホック多相だね
861デフォルトの名無しさん
垢版 |
2020/03/22(日) 11:43:59.28ID:F4lre3ad
>>853
ほんそれ
同じように思ってた人が居て良かった
2020/03/22(日) 12:55:36.51ID:q5xwUBc3
>>853
混同するのが危険なほど挙動が違うのなら、そもそも同じ関数名を使うべきじゃない。
関数・クラス設計における命名規則の問題だろ。言語設計(javaのヌルポ)の問題と関係ない。

この主張が、なんで型なしnullのマジックナンバー利用の肯定に繋がると考えているの？
2020/03/22(日) 15:36:31.56ID:HvrypJyW
>>857
「ポリモーフィズムは次のようないくつかの種類に分けられる：

・アドホック多相（Ad hoc polymorphism）：ある関数が、異なる型の引数に対してそれぞれ異なる実装を持つ場合。多くのプログラミング言語で関数の多重定義としてサポートされる。
・XXXX
・XXXX
・・・
」
864デフォルトの名無しさん
垢版 |
2020/03/22(日) 15:39:40.53ID:HvrypJyW
>>858
親Windowのポインタを受け取る引数にNULLとした場合、意味は分かり易い。
「親がない」こと以外に意味を取りようがないから。
同様に、メニューオブジェクトへのポインタをNULLとした場合も、
「メニューがない」こと以外に意味を取りようがないので分かり易い。

それに比べて、関数を多重定義した場合には、ミスによってとんでもない動作をしてしまうことが有り得る。
2020/03/22(日) 20:16:05.50ID:nwybfWiz
>>864
結局、関数の実装者がミスってnull参照エラーを起こすリスクは見えてないのか
2020/03/23(月) 01:38:55.49ID:bf1cRh+B
>>865
この例の場合、NULLにすると、それぞれ親Windowがない場合、Menuがない場合で、どちらも重要なので、さすがにテストしてあるはずなのだ。
この例に限らず、引数にNULLを指定する場合は、そのような「重要な変化」をもたらす事が多いので、必ずテスト済みの場合が多い故に安全なことが圧倒的多い。
2020/03/23(月) 02:26:57.24ID:dalJ4OEg
>>864
何を言いたいのか全然わからん。

NULLの利点は親Windowの指定方法だと言っているのに、
>>854だと全く関係のない関数funcでoverloadに問題があると言っている。
自分の主張に沿うようにいいとこ取りしすぎ。

同じケースでNULL利用の利点とoverloadの欠点を比較しろよ。

>親Windowのポインタを受け取る引数にNULLとした場合、意味は分かり易い。
nullよりも"NoWindow"というNullObjectを定義して使ったほうが意味はわかりやすい。
なんでnullを使わなきゃいけないのかね？
2020/03/23(月) 02:48:11.59ID:bf1cRh+B
>>867
後半、NULLで十分なのに敢えて、NoWindow なんてオブジェクトを定義する必要
を感じない。それでバグが減るわけでもないし。
2020/03/23(月) 03:14:15.98ID:6F6bSuZt
>>866
それは言い換えると、nullを安全に使えるのはテストのパターン漏れがあり得ないような重要な変化があるところに限られ、それ以外で使うと安全とは言えないってことだよな
「安全なことが多い」ってのは危険は残っていると認めてるね
「さすがに〜はず」ってのは希望的観測だし、最後の文だけ「圧倒的」を付け足したのも論拠不足だよな
人は多重定義で引数順を間違えるような凡ミスをすると理解できているんだ
では人が重要ではない甘いところでnullを不用意に使ってしまうミスは当然あるよな
2020/03/23(月) 08:20:48.10ID:E0UAbPRX
>>868
前半の準備できてから議論続けてね。


>「必要を感じない。」

それは個人の感想なので、主張としては弱くて役に立たないですね。

・メソッドを使う時に「NoWindow」であることをより明確化できる。
・間違えて「NoWindow」を指定してもnullより目立つので間違いに気づきやすい。
・名称がより明確なので、第三者がソースコードを読む時に読みやすい。
・それ専用に定義された変数に入っているので、IDEの支援を受けやすい。
・このケースだと必要性は薄いが、nullの意味が複数あるような場合でも(null,undefineなど)別々に定義できる。

くらいの利点はあるけど？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況