オブジェクト指向はオワコン？ part4

過去スレ
オブジェクト指向はオワコン (2023/08/26〜)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ (2024/07/19〜)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ part2 (2026/08/13〜)
https://mevius.5ch.io/test/read.cgi/tech/1786599483/
オブジェクト指向はオワコン？ part3 (2026/08/26〜)
https://mevius.5ch.io/test/read.cgi/tech/1787712923/

>>215
具体的には？

>>201
>テンプレートとかRustのトレイトとか挙げてるやん。
その2つはどっちも反例になってないでしょ
テンプレートは名前的型付けじゃないしRustのトレイトはインターフェース継承と同じで定義を継承してる

>>212
>>拡張トレイトやジェネリックは動的多態できないし、

Rustは拡張トレイトも静的ディスパッチと動的ディスパッチの両方できる
ジェネリックはC++でもRustでも静的ディスパッチで単相化するための文法
Rustではジェネリックにせずとも可能
普通の関数で静的ディスパッチと動的ディスパッチそれぞれを選んでどちらも使える
そんな至れり尽くせりの言語は他にないでしょう

>>トレイトオブジェクトはスーパートレイトを取り込む必要がある

Rustはスーパートレイトも含めてどれだけ大量のトレイトを指定しても静的に一つのvtableに取り込むことができるため柔軟性があるとともに動的ディスパッチが最も速い、が正解
これができない言語は複数のvtableを動的に見ていくことになって遅い

Rubyをdisるのはよせ

>>217
継承という語は、一般に部分型関係を作ることを目的とする構文という意味で使われるが、Rustのトレイトは部分型関係を作るものではない。一般的にもRustのトレイトが継承であるとは説明されない。
C/C++のテンプレートやPythonのプロトコルなんかを一種の構造的な型として観念する考え方は個人的には結構好きだが、言語仕様としての型（これらの言語において通常の意味での型とされる名前付きの型）と同様の扱いがされるわけではない。テンプレートが構造的型付け「に近い」とか、構造的型付け「的」とか、「一種の」構造的型付けといった、ちょっと含みのある表現で説明されることが多いのはなぜかを考えてみるとよい。

大体、そんなオレオレ定義・解釈を前提に「名前的型付けには型の互換性を指定する方法が継承しかない。だから、構造的型付けの方が優れている」とやっても誰も聞いてくれないでしょ。名前的型付けと構造的型付けの比較の文脈で、「テンプレートは構造的型付けだから構造的型付けの方が優れている」と主張することがどれだけ無意味か考えてみたら分かりそうなものだが。そんなことをしなくても構造的型付けには一定の価値は認められているよ。

オブジェクト指向で抽象メソッド/仮想メソッドを使うと便利でわかりやすくなるけど
実行が遅くなるため面倒でわかりにくい方法を選ぶ
という本末転倒な言語が存在する現実があるもんな
便利かつ速いの両立は重要

>>220
その通り
2種類の構造的型付けの用法がそこでなされていることに注目
1つ目は本来の構造的型付けで
「構造的に同じオブジェクトが同じ型とみなされ動く」
2つ目は構造的型付けではなく
「『あるメソッド』または『あるフィールド変数』が使われている関数では、それらを持つオブジェクトが動き、持たないオブジェクトはエラー」
ようするにダックタイピングであり構造的型付けとは明白に異なる

小さなプログラムではダックタイピングもお手軽で良いものだ
しかし大きなプログラムでは足を引っ張る存在になる
通過条件を名前で明瞭に指定できる方が好ましい

単純な例
関数fを通過できるxはhello()とbye()を持っていなければならないとすぐにわかるが
これがもっと大量に多段に複雑になると見通せなくなる
function f(x) {
f1(x)
f2(x)
}
function f1(x) {
x.hello()
}
function f2(x) {
x.bye()
}

fなんて名前つけてるからわかりにくいだけ

>>218
拡張トレイトって、
異なる複数のトレイトをあるトレイトTと同じになるように拡張トレイトで調整して、それら複数のトレイトを同じLIST<T>にトレイトオブジェクト無しに突っ込むとかできたっけ？

あとスーパートレイト～～は実行効率じゃなくて設計時の柔軟性(設計効率)の話だから、vtable云々はあんまり関係ないよ。

>>220
意図は>212の「設計の柔軟性」だから、上位型を早期に確定しないで後付けで部分型を使う反例があればぜひ。
普通はアダプタパターンだけど、言語レベルでサポートしてるの見たことないんだよね。

>>225
何に対する反例なのか、話の流れが見えないんだが。
名前的型付けにおいて、型の互換性を指示する方法として継承以外のものがあるか否か（>>171）という話だぞ。

>>220
テンプレートが名前的型付けじゃないことはわかったみたいだね

>Rustのトレイトは部分型関係を作るものではない
Rustのトレイトは部分型関係を作るためのものだよ
というかそのために存在してる
impl MyTrait For MyStructという宣言は
MyStructという型とimpl MyTrait/dyn MyTraitという型との部分型関係を作るもの

>だから、構造的型付けの方が優れている
これは曲解だね
俺はそんなこと全く思ってない
それぞれの特徴を理解して使い分ければいいだけ
最初に継承しかないと書いた人の意図は知らんけど

>>226
おっと、勘違いか。
無視してちょうだい。

>>225
拡張トレイトがExtention Traitの日本語訳ということなら
既存の構造体を拡張するのに新しくMyTraitを定義して
impl MyTrait for ForeignStructとすることで
ForeignStructに新しいメソッドを生やす手法のこと

>>227
C++のテンプレートは、それ自体としては名前的型付けでも構造的型付けでもないぞ。テンプレートによって観念される構造的な型を言語仕様上の型（C++における通常の型）と見てよいなら構造的型付けといってもよいが、C++の仕様はそうなっていない。
Rustのトレイトは部分型関係を作るというオレオレ定義がやりたいならどうぞご自由に。検索するなりAIに聞くなりして、Rustのトレイトは継承か、部分型関係を作るか、サブタイピング多相の一種かと聞いてみたらよいのに。

>>222
これぞ複オジメソッド！

>>220の二段目は普通のオツムをもってたら理解ができる文脈なんだが
>>227「これは曲解だね」と答えてるところからなんか可哀そうなものを感じる

オレオレ解釈を前提にしても誰も話きいてくれないよ？
逆に考えてみて？
こうだったらこうでしょ？
こうだったらこうでしょ？

↑この構造が理解できてないのは怖い
ひょっとしたら日本人じゃないのかもしれないねあの子は

具体的に>>197のtrait Helloの例を考えてみると
i32型はHelloの部分型になったと解釈することは可能で
str型もHelloの部分型になったと解釈することは可能であるが
問題はHelloを定義もしくはuse パス::Hello;したモジュール空間でしか部分型の関係が有効でないという点だ
つまりi32型が本質的にHelloの部分型になったとは言えない
このようにRustのtraitは柔軟性が高くて従来の枠組みで解釈しにくい

「Rustのトレイトは部分型関係を作るためのものだよ
というかそのために存在してる」

複クン語録がまたひとつ増えたな

>>234
Rustのトレイトを実装するとその型はそのトレイトの部分型関係になるのは事実
ただし有効範囲がそのトレイトの利用を宣言した範囲のみ
だからどちらも正しい
「本質的に部分型になったわけではない」
「その空間では部分型になっている」

つまりRustは既存のコードに全く影響を与えることなく
自分の空間内で新たな抽象型(trait)を導入して既存の型をその部分型にすることが可能
という柔軟性を持っていることになる

crate A の trait を
crate B の struct に
実装したいんだが

>>237
それは既存コードに影響を与えるから直接の実装は禁止されている
ラッピングして自分の型にして実装できる

自由度を失ってる

自由度ってなんだ？
何が失われている？

拡張メソッドはオブジェクト指向なのか？

>>197の例は既存のi32型のオブジェクトとstr型のオブジェクトが共にHelloという抽象型オブジェクトとしても扱えるようになった
オブジェクト指向プログラミングの利点の一つであるコードの共通化が可能になった

例えば抽象型Helloを受け付ける関数
fn hello_twice(x: impl Hello) {
x.hello();
x.hello();
}

共通してi32型もstr型もどちらも使える
hello_twice(123);
hello_twice("abc");

>>241
メソッドがすでにオブジェクト指向

>>242
HelloにFrom<i32>とFrom<&str>と
i32にInto<Hello>と
&strにInto<Hello>も実装するんやで

そんな悪手教えんなよ

>>243
メソッドと拡張メソッドは違うでしょうに
拡張メソッドはオブジェクト指向として邪道なのでは？

>>246
拡張メソッド ⊆ メソッド

なぜオブジェクト指向としては邪道だと思うの？

やっぱClassなど使わん方がすっきり書けるな

use v5.38;

package Hello {
　sub new ($class, $x) { bless \$x, $class }
　sub hello_twice ($self) { say "Hello! $$self" }
}

Hello->new(123)->hello_twice;
Hello->new('abc')->hello_twice;

use v5.38;
sub Hello ($x) {
　sub { say "Hellow! $x" }
}
Hello(123)->();
Hello("abc")->();

意図が全く伝わってなくて芝生える

うん、書いてて俺もそう思った

hello_twice()は2回helloだよ

>>244
そのHelloは抽象型
From/Intoは具象型同士の変換だよ
ではどうすればよいか？
二つの方法があります

一つ目は既に>>242に出ているimpl Helloで受け取る方法
fn hello_twice(x: impl Hello) {
x.hello();
x.hello();
}
これは単相化されて静的ディスパッチつまり普通の関数呼び出しになる
そのためインライン化などの最適化も行なえるから最も有利だね

呼び出す側は既に出ているようにそのまま渡せる
hello_twice(123);
hello_twice("abc");
これは値をそのまま渡しているけど
受け取り側をx: &impl Helloにすることで参照を渡すこともできるよ

もう一つの方法は&dyn Helloで受け取る方法
fn hello_twice2(x: &dyn Hello) {
x.hello();
x.hello();
}
これは動的ディスパッチになる
dynはもちろん動的の略
>>254の単相化とは異なりこの関数の実体が一つになることがメリット

呼び出しは引数のサイズを揃えないといけないから参照で渡す
hello_twice2(&123);
hello_twice2(&"abc");
そのため受け取り側も&が付いてx: &dyn Helloになってるよ

しかし動的ディスパッチは実行時にvtableを引くため遅いうえに
インライン最適化ができないためかなり遅い
それでもdyn Helloにしかできない魅力もある分かるよね

やりたいことに対して一番パーフォーマンスが出るものでやればよい
再利用なんてする必要もなくなった

動的ディスパッチのdyn Helloを使うのは実行時ガチャな時だな
どの具体型が返ってくるかわからないガチャ関数やガチャ式
あとはベクタ等へ混在して突っ込んで要素が実行時ガチャになる時
焦点はそこじゃなくてほとんどのプログラミング言語は抽象型の抽象メソッドが動的ディスパッチになって遅くなることだろ
一方でRustはガチャでなければdyn Helloをimpl Helloに変えるだけで静的ディスパッチになってインライン最適化も起きて劇的に速くなる

仮想メソッドは動的ディスパッチになって遅くなるから使うな！
という本末転倒の流儀まであるから草生える

これ>>256
人間が小さなワーキングメモリで考えやすく書きやすいように
人工的に小さく区切って部品化する必要がなくなってる

しかしAIなら多少区切りを大きく出来るとは言え完全になくすことは出来ないけど

>>256
パーフォーマンスが出る静的ディスパッチを選べない言語では、パーフォーマンスを断念するか、オブジェクト指向による抽象化を断念するかの二者択一になることがある

>>256
再利用ではなくて抽象型オブジェクトによるコードの共通化が必須
コードの読みやすさやメンテのしやすさがまるで違ってくる

C++はテンプレート使えば単相化静的ディスパッチになるけど
抽象型名を伴わない静的ダックタイピングな点や仮想関数による動的ディスパッチの時とコードが全く違ってくる点が残念だよな
Rustはトレイトの仮想関数そのまま静的ディスパッチと動的ディスパッチを簡単に切り替えられる点が大きい

何言ってるのかよく分からない
#include <concepts>
void hello_twice(std::derived_from<Hello> auto* x) {
x->hello();
x->hello();
}
でstd::derived_from<T, Hello>な型Tがfinalなら静的ディスパッチ、じゃなければ動的

動的ディスパッチが許されるのはメモリにメッセージをキューするときだけ
xをそれぞれのhellohelloのキューバッファにプッシュするときだけだ

上の例で言えばfinal以外は害悪
つまり継承は害悪

>>263
finalでなければ動的ディスパッチされる点でC++は敗北している
Rustとの違いが分かったかい？