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

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との違いが分かったかい？

そもそも既存のプリミティブ型を
>>197のように自分で作ったHello抽象型に属させることが出来ない言語と出来る言語があるような気がする

>>248は面白いぞ
数値型や文字列型をHelloの子供にする話なのにフィールドに入れてる

>>268
どうして数値をhelloの子どもにするんです？
オブジェクト指向ではないと思います

拡張メソッドは拡張にメソッドが生えてるだけでオブジェクトメソッドではない、オブジェクト指向において拡張メソッドは絶対悪

スタティックメソッドもオブジェクト指向ではない

オブジェクト指向の目的はカプセル化とコードの共通化
後者は異なる型に対して同じメソッド名で共通に呼べる多相性により実現される

具体的には例えば異なる具象型Aと具象型Bを一つの抽象型Xに所属させることで共通のメソッドを使えるようにする
これによりコードの共通化が実現される

抽象型Xの実現方法は各プログラミング言語それぞれの方法で構わない
たとえばクラスを用いる場合やインターフェースを用いる場合など各言語に適した方法が使われる

>>274
何も知らないなら何も言わないほうが良いぞ
馬鹿がバレるから

AとB二つの別々の型のオブジェクトに共通のコードを書く時
両オブジェクトを受け付ける抽象型を使ってコードを書いてるね

>>275
プログラミング言語は色んなのかあってピンキリだから各言語に適したやり方を許容するしかないんじゃない

うちはABCで抽象型を作ります