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

…簡単に…なったの…？

>>175
逆

何を簡単と呼ぶかの差かな～
クラス継承をしていくと密結合にデブって複雑なモノリシックになるから
最近は簡単に分けてクラス継承を使わずに合成しましょうって感じ

>>171
名前的型付けと構造的型付けで違いが出るのはサブタイピング多相の文脈だけじゃない？　テンプレートなどのパラメトリック多相とか、Rustのトレイト（アドホック多相の一種？）とかは、特に両者の対比とは関係ないと思う。

クラス継承はほんと害悪だが
人にもコンピュータにも

分散パイプラインという現実の工場と同じ流れになった
それ以外は些末
ベルトコンベアを詰まらせないことが至上命題

>>173
Beansっていつから言われなくなったのか

>>178
もちろんそんなことはない

>>178
型の同一性に関する話だからサブタイピングだけじゃないよ。

型の別名みたいに対称律が成り立つかどうかは大きく違うところ。

WindowsのGUIパーツが継承だらけなんだが

隠し名前フィールドまで設けて構造的型付けを使う必要性がないもんな
メリットなし

>>181
Java BeansはGUIアプリの技術だからな
GUIアプリがWebアプリで代替されるようになって
GUIコンポネント自体が廃れたのよね
Java Beansは20年前に死にました

Windowsを作ってるMicrosoftでさえ
WindowsのGUIよりもWebアプリを選んで
VSCode作ってるくらいだからな

ちなみにVSCode作ったのはオブジェクト指向のデザインパターンを考えた
GoFの一人エリック・ガンマ

もう自分じゃ書かないからどんなに記述がめんどくても実行パフォーマンスで最適なら構わん
AIにとって管理しやすいわけわからん言語になるんだろうなあ

道具にはそれぞれに適した用途と使い方があるにも関わらず
不適切な用途に使ったり不適切な使い方をしたりして
不都合な結果が出るとこの道具は使えないなどという結論を出す

もちろん本当に使えないのは道具ではなくて複おじのオツムです

AIにRustで書かせる例がどんどん増えてるね
メモリ消費が少なく速くて安全な言語が一番いいみたい

俺もRUSTにしてる、自分で見たくならないから

>>183
同一性の判断基準が異なるというのはもちろんだけど、>>171で話題にされているのが型の互換性だったからね。
型の別名というのが型エイリアス（処理系によって同視される型）のことなら名前的型付けと構造的型付けとで違いはないでしょう。ニュータイプ型の別名ならたしかに違いが出てくるけど、それは構造的型付けの方は余計に一手間掛かるという方向の違いだよね。
いずれにせよ名前的型付けにおいて、型の互換性を指示する方法として継承以外のものがあるという点は変わらないと思うけど。
個人的には名前的型付けの型システムに構造的型付けの機能を追加することについては、比較的好意的に捉えているけどね。Rustみたいな言語だとあまり必要性はないのかもしれないけれど、Pythonとかではかなりありがたい。

>>191
＞型の別名～～名前的型付けと構造的型付けとで違いはないでしょう。

ちょっと脱線してるけど、
(名前的型付け)名前で宣言しないと等価(置換可能)にならない
(構造的型付け)宣言しなくても構造が一緒なら等価(置換可能)
の違いがあるよ。

異なる名前を使っているのなら、
名前的型付けの場合は(名前の等価性を宣言しないと)別物。
構造的型付けの場合は名前ではなく構造を見るから等価性を宣言する必要が無い。

>>190
>自分で見たくならないから
そういうの大事よね

>>192
>>191で「名前的型付けと構造的型付けとで違いはない」と書いたのは、>>183の対称律の話ね。たしかにそこはちょっと言葉足らずだったかも。
192の内容は別に間違っていないけど、それは型システムの枠組みにおいては、結局サブタイピングの話でしょ。一般的な型システムにおいて、すべての型は自分自身の部分型（サブタイプ）なわけだから。プログラミング言語の構文としては通常区別されているから、別の話だとするのが間違いというつもりはないけどね。

> 娘の足が13.5になったから洗ってしまおうとして

ここから急激に難しくなるよな…

誤爆しましたごめんなさい
ついでと言ってはなんですが解読お願いします
i.imgur.com/rt3L9BV.jpeg

>>191
それはPythonにインターフェースを後付けできないから困っただけで名前的か構造的かは関係ないと思うんだよね
Rustのように後から新たなインターフェースをプリミティブ型に対しても実装できれば十分だよね
その件でも構造的型付けは不要だよ

// Rustはtraitがインタフェース相当
trait Hello {
fn hello(&self);
}

// 既存の数値型i32にHelloを実装
impl Hello for i32 {
fn hello(&self) {
println!("Hello! {self}");
}
}

// 既存の文字列型strにHelloを実装
impl Hello for str {
fn hello(&self) {
println!("Hello! {self}");
}
}

fn main() {
123.hello();
"abc".hello();
}

// 実行結果
// Hello! 123
// Hello! abc

構造的型付けはビルド時に勝手にコンパイラが適応出来る場合にやってくれればいいだけで
マは名前的で全部やってればいいんだよ

>>197
その例だとRustはもっと楽ができるぜ
実装コードがどれも同じなのでジェネリックにこれだけだ

impl<T: std::fmt::Display> Hello for T {
fn hello(&self) {
println!("Hello! {self}");
}
}

ちなみにprintは表示が可能な型が来ないと静的にエラーにしてくれる
それゆえ表示が可能な型＝Displayトレイト境界を与えてる

>>191
>いずれにせよ名前的型付けにおいて、型の互換性を指示する方法として継承以外のものがある
ある？
例えば？

>>197
Rustのトレイトのような機能があれば構造的型付けの強みはほとんどカバーできるという点は別に反対しないが、「名前的か構造的かは関係ない」というのは>>191のどの内容に対するコメントなのかよく分からないな。

>>200
>>176でテンプレートとかRustのトレイトとか挙げてるやん。

176じゃない、>>178だわ。

>>200
横からだが継承の定義がよくわからん
Rustだとその「型の互換性を指示する方法」は>>199のトレイト境界だよな

>>194
部分型は基本的に反対称律を持つから同値関係じゃなくて(半)順序関係だよ。

「Ｌ１はＵの別名、Ｌ２はＵの別名」としたとき、Ｌ１とＬ２は同じＵだから置換できるけど、
「Ｌ１はＵの部分型、Ｌ２はＵの部分型」としたとき、Ｌ１とＬ２は同じかどうかわからないから(Ｌ１、Ｌ２として)置換できるかもしれないしできないかもしれない。

>>171がどういう意味で継承を使ったのかは本人に聞いてみないと分からないが、自分は「型システム上の部分型関係を作ることを目的とした構文」くらいの意味で使っているけど。
構造的型付けの主な強みは、明示的な継承構文を使わなくても部分型関係が作れるところにあって、明示的な継承構文を使わないと部分型関係が作れない言語では構造的型付けの機能があると重宝する。ただ、Rustのトレイトみたいな機能がある場合は、既存の型に手を加えずに互換性のある型を定義するという同じことができるので、構造的型付けの強みは大幅に減殺される……というイメージ。

>>204
部分型関係が半順序関係であることを否定しているつもりは別にないのだけれど。対称律というのは183の関心点がそこにあるようだったから言及しただけで。
「名前的型付けで部分型関係を作るには継承等の明示的な宣言が必要、構造的型付けで部分型関係を作るにはそういう明示的な宣言は必ずしも必要ない」という基本理解の枠組みの中に>>192も位置付けることができるねというのが>>194の趣旨だけど、何かおかしい？

Pythonで開発している人たちによるPythonのProtocolについての説明記事を見ると
仕様を勧めないとか積極的に使わないと書かれてる
理由は構造的型付けだから

具体的にはProtocol名を用いて定義しないため分かりにくい可読性が低い保守性が低い
構造的に同じものが他にあると混乱する誤作動する安全でない
メリットよりデメリットの方が上回る

可読性ｗ
保守性ｗ

童貞が女の口説き方教えてくれとるわｗ

構造的型付けはProtocol名を用いて記述しなくても指定の構造さえ記述すれば済むというメリットがある！
と言いたいところだがそれを上回るデメリットを引き連れてしまうよな
構造的型付けを採用する言語が少ないのも仕方ないか

>>207
Protocolは実行時にメソッドがなくてエラーになってたのを
型チェッカーで実行前に洗い出せるようになるよってものなので
君が言うところの型安全ｗにはなると思うけどねえ
大きなメリットじゃないか

>>209
TypeScriptもPythonも動的型付けによるダックタイピングとの相性を考えて構造的型付けを採用してるわけ
少なくともTypeScriptやPythonではメリットの方が大きいと判断されてるというのは理解しようよ

>>205
継承についてはちょっと違って、
名前的型付けで上位型−部分型の関係を構成する方法
ということで「名前的型付け」がポイント。
構造的型付けの強みは表記の話もあるけど、それよりも「実際に部分型にするまで部分型を用意する必要がない」という設計上の柔軟性。

Rustは使ってないので間違えているかもしれないけど、拡張トレイトやジェネリックは動的多態できないし、トレイトオブジェクトはスーパートレイトを取り込む必要があるので「大幅に減殺される」という感じは無いなぁ。

Qiitaのこの記事？　「Pythonのtyping.ProtocolとABCの違いと実務的な考察」（https://qiita.com/sagong_ryung/items/140cc8ea35157fd184f5）
個人の見解みたいだけど、「人たち」による別の記事もあるのかな？
ちなみに、『ロバストPython』という本の13章（といっても10ページ程度）にProtocolについて分かりやすい説明がある。公式リファレンス以外の解説としては、個人的にはこちらの方を勧めたいかな。

自分は正直、上記のQiita記事があまり説得的とは感じないけど（もっとも、外部ライブラリや既存コードで使うのが良いとする点は妥当だろう）、個人の感想はいろいろだからね。推奨しないという人も居るんでしょう。

静的型付け言語にはメリットがないという主張なのね

>>212
貴方が動的多態の意味を勘違いしている

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

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

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

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

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

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

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

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

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

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

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

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

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

>>275
抽象型はclassよりinterfaceを使った方が好ましいだろうけどclassしかない言語もあるんだよ

プロトタイプしかない
後からclass表記も使えるようになったけど糖衣構文にすぎないため仕組みが違う

抽象化は自然言語の曖昧さが必要
実装言語にはいらない