オブジェクト指向はオワコン？ 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/

>>158
で、型安全性とは何かね？ おーん？ｗ

TypeScriptにおけるオブジェクトの型ってのはobject shapeのこと
typeやinterfaceはobject shapeのaliasでしかない
名前的型付け脳はまずここでつまづく

「型安全性」とやらに着目してはいけない
少し引いてみるといつも同じ構造になってる
いつもいつも同じ構造になってる

〇〇凄い→〇〇を備えてる言語凄い→Rust凄い→Rust応援隊の俺も凄い

これやりたいだけだからその子は
みんなも薄々見抜いてて遊んでんだろこれ

Rust凄いがやりたいなら、構造的型付けは型安全性を欠くみたいな意味不明な戯言ではなく、Rustのトレイトのような機能がある言語では、構造的型付けの強みは相対的に価値が低くなるとか、そういった方向性の立論にするのがふつうじゃない？

>>160
というよりも他の言語と違ってJavaScriptのオブジェクトは形は違えど1種類の型しかないことが敗因だよな
TypeScriptでもそれぞれの型注釈をそのまま直接書くかinterfaceやtypeで名前付けするくらいしかできないことが本質だよな

PythonだとJS/TSのプリミティブ相当まで全てがオブジェクト
しかしオブジェクトにきちんと型があって分かれているからJS/TSのような酷い状況になってない

オブジェクトに型の名前を付けて区別する機能が元々のJavaScriptにないんだよ
唯一できる区別が構造による区別だね
TypeScriptは構造的型付けが優れているから選んだのではなく仕方なくそうせざるを得なったに過ぎないんだよ

>>162
Pythonがiteratorを導入する時に後からiterator用の新たなABCを適用できないため
構造的に__next__と__iter__を持つオブジェクトをiteratorにした話も該当することに気付いた
Rustのトレイトはインタフェースや抽象クラスと違って後から新たなトレイトを適用できる柔軟性があるから
そのケースも構造的型付けにしなくて済むね

>>163
誰がどう見ても複おじのオツムが最大の敗因

あたまの悪さなのか
こころの病気なのか
いずれにせよ
気の毒なもんですよ

>>166
クラス継承がないから柔軟に適用できる
クラス継承が悪い

オブジェクト指向プログラミングに不要なクラスの継承を付けてしまったことはJavaの生みの親も後悔してた

名前的型付けで(型にしろインターフェイスにしろ)継承以外で互換性を指示する方法はないんじゃないんかな。
構造的型付けをサポートすれば解決するけど。

>>170
お前はそれを知ってどう思った？

昔は
・Interfaceを作る
・Interfaceを実装するAbstract Classを作る
・Abstract Classを継承してClassを作る
というのが一連の流れじゃったなあ
Abstract Classを挟むのはInterfaceのメソッドをClassごとに実装するのが大変だったから
いまは簡単になったんかいの？

現代のオブジェクト指向プログラミング
・クラス継承は使わない
・共通の変数(群)がある時はそれを独立させて合成して委譲する
・他に共通のメソッドがある時は共通インタフェースを作ってそれを実装する

…簡単に…なったの…？

>>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に変えるだけで静的ディスパッチになってインライン最適化も起きて劇的に速くなる

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