オブジェクト指向って自然な文法だな 3 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/04/02(日) 16:30:38.65

前スレ
オブジェクト指向って自然な文法だな 2
http://echo.2ch.net/test/read.cgi/tech/1490506257/

**デフォルトの名無しさん** · 2017/06/18(日) 02:09:35.32

「せんし」に「たたかえ」送るとプレイヤーは細かいこと指示しなくても自分で戦ってくれる。
これはあくまでモデル上でのすっきりした切り分けの話であって、こういうオブジェクト化に
「戦場で仲間に"たたかえ"ってなんだよw」とか「順番に交互に殴るのかよ」とか言ってもまったく無意味だというのに
キャットドアじじいはなんかそういうことから理解できてない知恵遅れだからね。

**デフォルトの名無しさん** · 2017/06/18(日) 02:54:24.42

オブジェクト指向の話をしていると
よく勘違いしてるやつが出てくる。

オブジェクト指向で現実世界を実現しようとするやつだ。
シミュレーションでもやらない限りそんなものは意味がない。

その逆、実現したいものを現実世界をヒントに
オブジェクト指向でモデル化するんだよ。

そうすることで現実世界という共通認識を利用して
実現したいものをわかりやすく表現することができる。

**デフォルトの名無しさん** · 2017/06/18(日) 06:41:42.42

雲をつかむような話でわからん
具体例かいてくれ

**デフォルトの名無しさん** · 2017/06/18(日) 06:56:57.61

あくまでモデルであり振る舞いをシミュレートしてるだけ

**デフォルトの名無しさん** · 2017/06/18(日) 06:57:50.55

ドア本体とそれに付属するノブの状態（「開閉」と「回す、離す」）、
ノブに付属するラッチ（固定具）の状態（ノブの回転に応じて引っ込む）
をオブジェクト指向でモデリングしてみてよ

オートクローザーやドアストッパーが設置されることも加味しつつ

**デフォルトの名無しさん** · 2017/06/18(日) 07:37:54.80

「たたかえ」送ってないのに勝手に雑な戦いを始めたがる「ばか」たち

**デフォルトの名無しさん** · 2017/06/18(日) 07:37:54.40

勘違いの典型

**デフォルトの名無しさん** · 2017/06/18(日) 07:53:36.83

現実世界とか言い出すといくらでも後出し要件が出てくる。
「でも現実を見てみなよ」って。
モデリング終わりがなくなってしまうわけだ。
そういうバカには5000兆円の見積書でも送りつけてやればいい。

**デフォルトの名無しさん** · 2017/06/18(日) 08:07:11.57

物事を分類整理するための手法なのだから管理する要件でない不用な要素は極力排除しないとな

**デフォルトの名無しさん** · 2017/06/18(日) 09:07:26.63

相互作用という物理では当たり前の考え方を
理解できない文系のためのモデリング
それがオブジェクト指向

**デフォルトの名無しさん** · 2017/06/18(日) 11:56:10.30

>>824
例えば>>826のようの

現実世界にある何か（ドア）をオブジェクト指向で表現してくれ
なんていう考え方がアホなんだよ。

ソフトウェアでドアを作ることがあるとしたら、
ゲームとかだろうけど、ゲームとして必要なドアを
ソフトウェアで実現するならば、オブジェクト指向が便利ですね

なぜなら、ゲーム世界のドアをオブジェクトとして実装することができるので
現実世界で我々がよく知ってるドアを参考にできるからです。

ってな具合

**デフォルトの名無しさん** · 2017/06/18(日) 13:56:58.20

文系って言い方はあれだけど、物理法則を因果関係的に捉えてるのかもな。
あれがこうしたらこれがこうなる、みたいに。

**デフォルトの名無しさん** · 2017/06/18(日) 14:23:38.73

理系って言い方はあれだけど、物理法則を因果何的に捉えてるの？

理系 · 2017/06/18(日) 14:27:11.50

>>834
因果応報。

**デフォルトの名無しさん** · 2017/06/18(日) 14:30:00.44

人間って何歳の頃から、現実世界を
オブジェクト指向として認識するのだろうか？

同じ人間であっても自分の母親と他人の母親は別だって
理解できるし、人間と動物の区別もついているだろう。
そして、犬はワンワン、猫はニャーニャーって鳴くことを
理解するだろう。

人間の認識とはかくもオブジェクト指向であるものだろうか

**デフォルトの名無しさん** · 2017/06/18(日) 15:46:42.41

因果何的？

**デフォルトの名無しさん** · 2017/06/18(日) 19:18:13.12

>>832
ゲームのドアなんぞ開く閉じるの状態と、開く条件(鍵とか)ぐらいだろ。

んで、自動ドア制御とかだとセンサーから信号が来た時だけ開いて、数秒したら閉じれば良い。
人が通った時の赤外線センサーか、人が挟まった時の圧力センサーかはプログラムは知る必要無い。

これらに共通のドアクラスなんぞ作って何か共通点があるの？

**デフォルトの名無しさん** · 2017/06/18(日) 19:24:10.12

>>838
開く閉じるの状態があるのは開口部のほうやけんど？

**デフォルトの名無しさん** · 2017/06/18(日) 21:49:56.86

開口部ってなんですか？

**デフォルトの名無しさん** · 2017/06/18(日) 21:51:50.67

>>839
それは現実世界のドアの話だろう？

ゲームの世界のドアは、現実世界を参考にできるが
ゲーム特有のドアという仕様を作る。

3Dゲームであれば、ドアには開く閉じるという状態は必要ないだろう
なぜなら物体をすり抜けられないという仕様と
蝶番を支点にドアを動かせるという仕様があればよいからだ

だけど2D RPGみたいなドアであれば、ドアの状態というものがあってもよい
開いているドアであれば、その上を移動することができ、
取っじているドアであれば、その上に移動することはできない。

このようにオブジェクト指向は現実世界の物シミュレートためのものじゃなくて
作りたい仕様を、みんなが持っている現実世界の共通認識を使って
わかりやすくする表現するための技術なんだよ

それにしても現実世界のドアについての人間の認識ってのも面白いよな。
ドアからすれば、物理的にはどういう位置にあるかでしかないのに、
人間は「開いている」「閉まっている」というドアの状態として認識しているわけだ
この認識、利用しない手はない！

**デフォルトの名無しさん** · 2017/06/18(日) 21:54:52.64

>>841
開口部の状態だって教わったのに意地はっちゃってw
ドアオブジェクトなんてそもそも必要ないんや
こーゆーのをモデリングゆーんやわかったかボケカス

**デフォルトの名無しさん** · 2017/06/18(日) 21:57:16.87

>>842
開口部って何って聞かれてるんだから
質問に答えなよｗ

**デフォルトの名無しさん** · 2017/06/18(日) 22:01:44.39

アスペだと「ドアが開いている」ときいて

ドアが開いているとか意味がわからない
開口部があってそこがドアというもので塞がれているかどうかだ。
だから「開口部がドアで塞がれていない」と言うべきだ

とか思うのだろうか？

アスペには常人の共通認識は通用しない
オブジェクト指向には不向きな人間だなｗ

**デフォルトの名無しさん** · 2017/06/18(日) 22:09:09.19

>>844
なあ？お前の考えた最強の抽象化ってぜんぜん抽象化じゃなかっただろ？
恥ずかしいけどこれで一つ賢くなったんだ
次はもう少し長くドヤれるようになるじゃないかw

**デフォルトの名無しさん** · 2017/06/18(日) 22:11:24.68

>>845
誰が最強の抽象化とか言ったんだ？
お前はだれと戦ってるんだ？

俺の言ってることに何一つ反論して無くて
俺のほうが正しかったと主張してるだけ
妄想も大概にしろよ。

**デフォルトの名無しさん** · 2017/06/18(日) 22:14:21.01

>>846
え？お前なんか意味のある事言ってたの？
じゃあもう一度言ってみ？聞いてやるからw

**デフォルトの名無しさん** · 2017/06/18(日) 22:15:23.98

抽象化というのは本質的な所

ドアには開いている・閉じているという
状態があると認識することだよ。

本当は開口部だーとか細かいことに
こだわるのは抽象化とは逆の考え

はい論破♪

**デフォルトの名無しさん** · 2017/06/18(日) 22:15:46.63

>>847
もう一度言えばいいの？

それは現実世界のドアの話だろう？

ゲームの世界のドアは、現実世界を参考にできるが
ゲーム特有のドアという仕様を作る。

3Dゲームであれば、ドアには開く閉じるという状態は必要ないだろう
なぜなら物体をすり抜けられないという仕様と
蝶番を支点にドアを動かせるという仕様があればよいからだ

だけど2D RPGみたいなドアであれば、ドアの状態というものがあってもよい
開いているドアであれば、その上を移動することができ、
取っじているドアであれば、その上に移動することはできない。

このようにオブジェクト指向は現実世界の物シミュレートためのものじゃなくて
作りたい仕様を、みんなが持っている現実世界の共通認識を使って
わかりやすくする表現するための技術なんだよ

それにしても現実世界のドアについての人間の認識ってのも面白いよな。
ドアからすれば、物理的にはどういう位置にあるかでしかないのに、
人間は「開いている」「閉まっている」というドアの状態として認識しているわけだ
この認識、利用しない手はない！

**デフォルトの名無しさん** · 2017/06/18(日) 22:18:27.67

ドアが開いている、閉じているという話をする時
開口部なんて細かい枝葉は誰も考えてないって所が重要だね。

まあ密室殺人で警察に聞かれた時に
この部屋の開口部はドアで塞がれていましたなんて
言わないのと同じこと。

**デフォルトの名無しさん** · 2017/06/18(日) 22:22:00.29

>>848
ドアって開口部を制御するための具体的実装の一例にすぎんのだかw
抽象とは真逆の概念ですよ？オブジェクトハカセw

**デフォルトの名無しさん** · 2017/06/18(日) 22:28:26.80

>>851
だから、お前、オブジェクト指向を現実世界をシミュレートするために使うなって
それが間違ったオブジェクト指向の解釈なんだよ。

ドアを抽象化して考えろ。細かい枝葉は取り除け

抽象化
https://ja.wikipedia.org/wiki/%E6%8A%BD%E8%B1%A1%E5%8C%96
> 抽象化（ちゅうしょうか、英: Abstraction、独: Abstraktion）とは、
> 思考における手法のひとつで、対象から注目すべき要素を重点的に抜き出して他は無視する方法である。

https://goo.gl/soXPyb
> ▼誤解されがちな、「抽象化」という言葉
> 結構な人々が抽象化を「曖昧にすること」とか思っていて、抽象絵画は「なんか曖昧な絵」みたく思っているので始末に負えない。
> まず「抽象（abstraction）」っていうのは、「物事の共通部分を抽出して把握すること」だ。
> 「対象物の特徴をつかみ、枝葉を切り捨てた本質をとらえる」思考力を抽象化思考力と呼びます。
> コンサルタントが「抽象度をあげろ」というときには、実は「抽象的にしろ」とは言っていません。「概念化して語れ」と言っているのです。

**デフォルトの名無しさん** · 2017/06/18(日) 22:30:11.78

具体的実装（抽象化の逆）とか言ってるからこれも引用しておくべきだったｗ

> 抽象化とは、一般化（上位の概念に包括）することです。例えば亀→両生類→動物→生物という具合に、上位の分類の言葉に置き換えていくことです。

**デフォルトの名無しさん** · 2017/06/18(日) 22:32:10.52

>>852
お前が抽象化できんかったからドアが残ったって言いたいんだろ？
知ってるってw
ハカセそれ抽象化ちゃうw細分化やw

**デフォルトの名無しさん** · 2017/06/18(日) 22:33:52.30

>>854
ドアが残ったってなんだ？
またお前が言い出した言葉を
俺が言ったことにしたいのか？

お前が言い出した言葉に対して、「知ってるってｗ」って
なに自分で自分にレスしてるんだ？

妄想も大概にしろ

**デフォルトの名無しさん** · 2017/06/18(日) 22:34:51.41

「ドアが残った」＝それは細分化や

これも意味がわからん。
こいつバカなのか？

**デフォルトの名無しさん** · 2017/06/18(日) 22:38:08.14

双方何が言いたいのかわからん

**デフォルトの名無しさん** · 2017/06/18(日) 22:38:14.46

>>855
端的に言ってお前支離滅裂だぞ
少なくとも今夜俺は
お前に抽象化のなんたるかを垣間見せてやったのだから
明日からもう少しまじめに勉強しろよ
まあ今夜は恥ずかしくて顔から火がでてるだろうから
多少の発狂は仕方ないけどなw

**デフォルトの名無しさん** · 2017/06/18(日) 22:40:28.64

> お前に抽象化のなんたるかを垣間見せてやったのだから

え？どれ？
具体的実装の話をすること？

それは抽象化の逆だけど？

**デフォルトの名無しさん** · 2017/06/18(日) 22:42:55.55

これ、自分のことを話してるのかな？

> 端的に言ってお前支離滅裂だぞ
ID:ZkAshefq が支離滅裂

> 少なくとも今夜俺は
> お前に抽象化のなんたるかを垣間見せてやったのだから
ID:ZkAshefq に俺が見せてやった

> 明日からもう少しまじめに勉強しろよ
ID:ZkAshefq が勉強しろ

> まあ今夜は恥ずかしくて顔から火がでてるだろうから
ID:ZkAshefq が恥ずかしくて顔から火が出てる

> 多少の発狂は仕方ないけどなw
ID:ZkAshefq が発狂している。

本当は自分のことなのに、それをごかます
幼稚なやつがやる手段だなぁ

**デフォルトの名無しさん** · 2017/06/18(日) 22:44:07.16

コイツは根本的に馬鹿なのか？
はたまた恥ずかしすぎてトボケてるだけなのか？
いまのところ前者が優勢ですけどねw

**デフォルトの名無しさん** · 2017/06/18(日) 22:44:08.65

>>857
俺が言いたいのはこれ（三度目のコピペ。二度目はID:ZkAshefq にもう一度書けと言われて書いたのに無視されたｗ）

それは現実世界のドアの話だろう？

ゲームの世界のドアは、現実世界を参考にできるが
ゲーム特有のドアという仕様を作る。

3Dゲームであれば、ドアには開く閉じるという状態は必要ないだろう
なぜなら物体をすり抜けられないという仕様と
蝶番を支点にドアを動かせるという仕様があればよいからだ

だけど2D RPGみたいなドアであれば、ドアの状態というものがあってもよい
開いているドアであれば、その上を移動することができ、
取っじているドアであれば、その上に移動することはできない。

このようにオブジェクト指向は現実世界の物シミュレートためのものじゃなくて
作りたい仕様を、みんなが持っている現実世界の共通認識を使って
わかりやすくする表現するための技術なんだよ

それにしても現実世界のドアについての人間の認識ってのも面白いよな。
ドアからすれば、物理的にはどういう位置にあるかでしかないのに、
人間は「開いている」「閉まっている」というドアの状態として認識しているわけだ
この認識、利用しない手はない！

**デフォルトの名無しさん** · 2017/06/18(日) 22:45:29.07

>>857
オブジェクト指向は抽象化して考えるためのものでもあって
どういう具体的実装であるかは置いといて、
「ドアが開いてる・開いてる」という状態で表現できるわけよ

**デフォルトの名無しさん** · 2017/06/18(日) 22:50:00.87

もはや完全に意地になってるなw
学習できない奴の特徴まんまw

**デフォルトの名無しさん** · 2017/06/18(日) 22:52:43.90

>>864
ごめん。もうお前にレスはしてないんだｗ

**デフォルトの名無しさん** · 2017/06/18(日) 23:21:09.03

開口部ってなんですか？
ドアとどう関係があるんですか？

**デフォルトの名無しさん** · 2017/06/18(日) 23:30:56.67

おまえらがどう対立してるのかがわからん
オブジェクト志向には色々な側面があるんだし、その二つは別に対立せん気がするが

**デフォルトの名無しさん** · 2017/06/18(日) 23:35:28.24

対立じゃなくてオブジェクト指向は現実世界のものをシミュレート
するものじゃないってことを言ってるだけだよ。

オブジェクト指向で現実世界のあれができないこれができないっていうのは
的外れだってこと

ま、そもそもオブジェクト指向で「ドア」を実装するにはどうすればいいだ？って
ドアというオブジェクトを持ってきてる時点で、
オブジェクト指向は人間の認識と相性が良いんだってわかるんだけどねｗ

**デフォルトの名無しさん** · 2017/06/18(日) 23:57:27.96

あ、違うID:ZkAshefqは俺にレスしてないのか
すまんやっぱり>>867はなしで
>>868
主張のまとまりがいまいち良くないけど、好意的に解釈する限り言ってることは間違ってないと思うよ

**デフォルトの名無しさん** · 2017/06/19(月) 01:13:21.02

どっちも主張がよーわからんが
ID:ZkAshefqを抽出したらびっくりするほどなんにも言ってなかった。
「ばーかばーかおれの勝ちィ！」しか書いてなくね？
なんでスレ進んでんの？

**デフォルトの名無しさん** · 2017/06/19(月) 01:19:07.10

https://ja.wikipedia.org/wiki/Simula
Simula 67 ではオブジェクト、クラス、サブクラス、継承、動的束縛（仮想関数）、
コルーチン、ディスクリートイベントシミュレーション、ガベージコレクションの機能をもち、
オブジェクト指向プログラミングの基本概念はすべてここで発案されているといえる。

Simula はプログラミングパラダイムとして最初のオブジェクト指向言語であると考えられる。
その名前が示すように Simula はシミュレーションを行うために設計され、
その必要性から今日のオブジェクト指向言語で使われる多くの機能のためのフレームワークを提供した。
なお、Simula 当時「オブジェクト指向」という言葉はまだない。
この用語はアラン・ケイが Simula の概念として70年代ごろに使い出したのが始まりといわれている。
従ってその意味では Simula が世界最初のオブジェクト指向言語であり、
Simula は「オブジェクト指向として再認識が可能な最古の言語」ということができる。

**デフォルトの名無しさん** · 2017/06/19(月) 01:25:04.44

>>870
> ID:ZkAshefqを抽出したらびっくりするほどなんにも言ってなかった。
だろ？ｗ

**デフォルトの名無しさん** · 2017/06/19(月) 01:27:16.04

志村けんは、日本のコメディアン、お笑いタレント、司会者。ザ・ドリフターズのメンバー。
生年月日： 1950年2月20日 (67歳)

https://ja.wikipedia.org/wiki/Simula
志村(67) ではオブジェクト、クラス、サブクラス、継承、動的束縛（仮想関数）、
コルーチン、ディスクリートイベントシミュレーション、ガベージコレクションの機能をもち、
オブジェクト指向プログラミングの基本概念はすべてここで発案されているといえる。

志村はプログラミングパラダイムとして最初のオブジェクト指向言語であると考えられる。
その名前が示すように志村はシミュレーションを行うために設計され、
その必要性から今日のオブジェクト指向言語で使われる多くの機能のためのフレームワークを提供した。
なお、志村当時「オブジェクト指向」という言葉はまだない。
この用語は荒井・注が志村の概念として70年代ごろに使い出したのが始まりといわれている。
従ってその意味では志村が世界最初のオブジェクト指向言語であり、
志村は「オブジェクト指向として再認識が可能な最古の言語」ということができる。

**デフォルトの名無しさん** · 2017/06/19(月) 01:28:38.27

>>871
シミュレーションをするための言語を作ると
オブジェクト指向になるってのは
やはりオブジェクト指向は現実世界の人間の認識と
相性がいいってことなんだろうね。

**デフォルトの名無しさん** · 2017/06/19(月) 01:44:56.66

>>871
毎回思ってることだけど、アランケイのオブジェクト指向のポイントは
むしろメッセージセンドでオブジェクトに命令を送るという方式の発案なので
(さらにいうと、インスタンスを作るのにクラスそのものに「複製を作れ」と命令して作らせる
言語システム(予約語)から離れてクラスが自律的に動く思想の方)
Simulaはかなり毛色の違うオブジェクト指向だし
言ってしまうとこれがカンチガイされたままオブジェクト指向だと思われた結果
C++というそびえ立つクソの山が産まれて業界を何十年も混乱に陥れた元凶だから
Simula持ってきて「オブジェクト指向とは～」ってやった瞬間

お話にならないぐらいオブジェクト指向を理解していないバカが来た。

で話が終わるんだけど。

**デフォルトの名無しさん** · 2017/06/19(月) 01:57:02.13

そういやエージェント指向ってどうなんたんかな？
昔、15年ぐらい前に学生だった時に先生がこれからはエージェント指向だって言ってたんだが
その説明きいて、俺はそれってオブジェクト指向＋メタデータじゃね？程度に思ってた。

オブジェクトが自律的に仕事をする。みたいな事を言ってたんだが、
それを実現するにはどんな要望であっても、それを実現するためのモジュールが存在し
その要望を完璧に判断してモジュールを選択できるAIでも搭載してなきゃできないような
ものだったのでエージェント指向でもなんでもないし実現は不可能と思っていたが。

まあエージェント指向とやらにはさっさと見切りをつけたので
俺が間違って理解してるんだと思うけどねｗ
でも事実としてオブジェクト指向を置き換えるものにはならなかったようだね。

**デフォルトの名無しさん** · 2017/06/19(月) 02:06:51.24

>>875
シミュレーションをするために言語を作ったけど、
本来の用途としてはあまり使われず、（よくよく考えてみれば
シミュレーションなんてそんなにするか？ってことなんだろう）

副産物として生まれてオブジェクト指向の技術の基礎とでも
呼べるようなものが独立しそれが洗練されてオブジェクト指向言語
として生まれ変わったってことなんかね。

UMLも似たようなもんだよね。元々はオブジェクト指向分析や設計の方法を
色んな人が考えていたけど、それぞれを比較検討する時、それぞれで図の書き方が
異なっていたので、分析や設計方法が色々あるのはわかる。だけどせめて図の書き方
ぐらいは統一しようじゃないかって生まれたもの。

でもオブジェクト指向の分析や設計方法はみんな飽きてしまったのか話題にならなくなり
UMLという図の書き方だけが広まったと。

**デフォルトの名無しさん** · 2017/06/19(月) 08:54:27.70

歴史的な起源に拘らない人と、
「もともとはこうだったのに変質してしまった。クソが！」と思う人がいるのだなあ。

と感じました、まる

**デフォルトの名無しさん** · 2017/06/19(月) 10:38:29.48

歴史的な起源に拘らないとsmalltalkerなんてやってられないよ

**デフォルトの名無しさん** · 2017/06/19(月) 11:06:11.95

ストラウストラップとケイの“オブジェクト指向”は別物なので混同せずちゃんと区別したほうがよい

ストラウストラップの“オブジェクト指向”はSimulaスタイルのクラスを抽象データ型（ADT）とみなして使うアイデア
抽象データ型の提唱者のリスコフ、Simulaの設計者たち（ダールとニガート）はもちろん、メイヤーも同様のアイデア同時期に提示している
抽象データ型というのは簡単にいうと「ユーザー定義型」のことで言語組み込みの具象データ型に対してこう呼ばれる
OOPの古典的三点セット「カプセル化・継承・ポリモーフィズム」に象徴されていて
カプセル化は抽象データ型の要件、継承とポリモーフィズムはクラスを使う際のオマケの機能を表わしている
ただ、早々にクックらにより継承を使ってサブタイプを表現することには問題が生じうることが指摘されていて
また動的型のダックタイピングのような自由度を得るためにインターフェース（プロトコルなど別の呼び名も）が考案され
現在はそれが汎用されている

一方、ケイの“オブジェクト指向”はSimulaのオブジェクトにメッセージの受け手を担当させるアイデア
メッセージングはあくまで方便で狙いはその先の設計・実装・運用等、あらゆる局面での「遅延結合の徹底」
遅延結合というと実装のみに固執してしまう人がいるから「決定の遅延」といった方がよいかも
Smalltalk-72はこのアイデアを元に、クラスはJSのクラスのような関数っぽい性質で実現された
このときはメソッドも関数というよりLISP等のリーダーマクロのようなメッセージとなるトークンストリームを順次処理する手順が記述された
次の世代のSmalltalk-76からはSimulaスタイルのクラスが取り込まれ、メソッドも単なる関数になり
前者のオブジェクト指向もそれなりに意識されるようになったので同じSmalltalkでも
Smalltalk-72は純粋なメッセージングのOOPL、Smalltalk-76以降はADPとメッセージングのキメラと考えた方がよいので
もしケイのメッセージングのOOPの考え方に興味があるならPharoやSqueakのような最新のSmalltalkではなく
エミュレーター等で提供されているSmalltalk-72をやるほうがいい
https://ubiteku.oinker.me/2016/05/09/what-is-oo-all-about/#comment-65
ちなみにアクター理論はこのアイデアを実行時の並行性に応用し定式化を試みたもの

**デフォルトの名無しさん** · 2017/06/19(月) 11:42:12.84

実用的な言語の話をしている

**デフォルトの名無しさん** · 2017/06/19(月) 16:38:13.20

決定の遅延とは即ち実行時に決定するということ
つまりデータと処理の抽象化を徹底するということだ

**デフォルトの名無しさん** · 2017/06/19(月) 16:49:21.59

データの抽象化を徹底すると型とクラスが無くなる
型によってデータ長も処理の方法も変わるのが煩雑さの根源だ

**デフォルトの名無しさん** · 2017/06/19(月) 19:55:43.12

もともと、コンピュータが巨大にそしてネットワークで接続されると
離れたユニットに「この処理をお願いします」と頼むことになって
シーケンシャルな処理待ちしていたらコンピュータが止まっちゃうし
周りの環境も実行時に刻々と変化してゆくから
オブジェクトにはある種の他と切り離された自律性がいるよね。なのに
なぜか21世紀のインターネット時代に「いいや！カッチリ制御して
他に影響が出ないように書ければこの『世界が勝手に変化するバグ』は排除できるはずだ！」
という謎のカルトが一部で流行り出してるのがどうにもよくわからないw

**デフォルトの名無しさん** · 2017/06/19(月) 21:05:37.05

ガイジ

**デフォルトの名無しさん** · 2017/06/19(月) 23:09:44.33

歴史的にオブジェクト指向の後にテンプレートとかジェネリックとか言われるのが導入されたけど、継承とかより移譲が重宝されてる辺り、ジェネリックだけで十分じゃね？って気がしなくも無い。

**デフォルトの名無しさん** · 2017/06/19(月) 23:22:30.80

C++以外にテンプレートがある言語ってあるの？

C++のテンプレートは本来ジェネリック程度の機能で良かったのに
ちょっと道を外したら、意外と高度なことができることが分かっちゃって
本来の目的から大きくはずれてコンパイル時コードジェネレータみたいな
もんになっちゃったでしょ？

**デフォルトの名無しさん** · 2017/06/19(月) 23:28:36.65

そもそも継承なんてものの80%はゴミ
protcolとdelegateこそが至高

**デフォルトの名無しさん** · 2017/06/19(月) 23:30:58.96

そういのいいんで

**デフォルトの名無しさん** · 2017/06/19(月) 23:33:07.34

そういやこの1スレたてたガイジ最近みないね

**デフォルトの名無しさん** · 2017/06/20(火) 23:04:56.68

Haskellでガンガンよく使う処理を個人ライブラリ化なう。

Myfunc.hs
1:module Myfunc where
2:
3:import Data.List
4:import Text.Printf
5:
6:consnum::(Int,String) -> String
7:consnum (i,xs) = printf "%4d:%s" i xs
8:
9:fline f = unlines.f.lines
10:
11:fnumbering f = fline ((map consnum).(zip [1..]).f)
12:
13:numbering = fnumbering id
14:
15:revnumbering = fnumbering reverse
16:
17:allrevnumbering = fnumbering (reverse.map reverse)
18:
19:searchword w = fline (filter (isInfixOf w))
20:
21:putfc (f,c) = printf "%s\n%s" f c
22:
23:mulfileput fs f = mapM readFile fs >>=
24: return.(zip fs).map f >>=
25: mapM_ putfc

**デフォルトの名無しさん** · 2017/06/20(火) 23:05:26.93

number.hs
1:import System.Environment
2:import Myfunc
3:
4:main = getArgs >>=
5: \fs -> mulfileput fs numbering
6:
revnumber.hs
1:import System.Environment
2:import Myfunc
3:
4:main = getArgs >>=
5: \fs -> mulfileput fs revnumbering
6:
searchword.hs
1:import System.Environment
2:import Myfunc
3:
4:main = getArgs >>=
5: \(w:fs) -> mulfileput fs ((searchword w).numbering)
6:

**デフォルトの名無しさん** · 2017/06/20(火) 23:52:17.95

だからそういうのはブログで……

**デフォルトの名無しさん** · 2017/06/21(水) 00:42:37.70

ん。
だってオブジェクト指向言語使ってた時って、ここまで似たようなコード書かなくて良いくらいライブラリ化出来たことなかったんだもん。

**デフォルトの名無しさん** · 2017/06/21(水) 00:55:18.54

readFileの中身が謎だらけで怖くて使えない

**デフォルトの名無しさん** · 2017/06/21(水) 01:08:07.93

PythonやRubyのopenと大差ないと思うが。。。
嫌ならもっと低レベルの関数もあるよ？

**デフォルトの名無しさん** · 2017/06/21(水) 07:06:46.09

型クラスの仕組みが姑息
LISPのSETFと同じくらいガッカリ感ある

**デフォルトの名無しさん** · 2017/06/21(水) 07:08:04.36

猫ドアは後出しでドアの要件増やされるけどインターフェイスで振る舞いを追加してけば対応可能じゃないの

オブジェクト指向言語的に考えたら

**デフォルトの名無しさん** · 2017/06/21(水) 08:08:08.40

>>898
それはインタフェース自体を増やすと言ってるように聞こえるけど？

**デフォルトの名無しさん** · 2017/06/21(水) 08:31:13.44

>>898は新規インターフェイスの追加じゃなくて既存のインターフェイスへ機能追加だろ

**デフォルトの名無しさん** · 2017/06/21(水) 08:32:01.05

new ってなんなのか、なぜ必要なのか教えて、
オブジェクト生成元クラスのコンストラクタ関数の結果を得るだけなら、
Foo obj = Foo();
とすれば new なくても書けるのに、なぜ new を書く必要があるの?

**デフォルトの名無しさん** · 2017/06/21(水) 08:55:18.55

newがあるから僕らはそれがコンストラクタを呼ぶものだと知ることができる
newがなければ何をすれば良いのかわからない
コンパイラの気持ちになって考えろよ

**デフォルトの名無しさん** · 2017/06/21(水) 09:09:53.08

newをかかなくていい言語をさがそう

**デフォルトの名無しさん** · 2017/06/21(水) 09:11:42.85

C++の例

Base *base_pointer = new Base();
Base base();

**デフォルトの名無しさん** · 2017/06/21(水) 09:19:49.52

pikeという言語は、newをつかわない

bird tweety = bird("Tweety", 0.13);
tweety->eat("corn");
tweety->fly();
tweety->max_altitude = 180.0;

fish b = fish("Bubbles", 1.13);
b->eat("fish food");
b->swim();

animal w = fish("Willy", 4000.0);
w->eat("tourists");
w->swim();

Inheritance | Object-Oriented Programming | Beginner’s Tutorial - Pike Programming Language
https://pike.lysator.liu.se/docs/tut/oop/inheritance.md

**デフォルトの名無しさん** · 2017/06/21(水) 10:28:20.88

new要らないな

**デフォルトの名無しさん** · 2017/06/21(水) 10:47:23.25

コンパイラが進化すればいらなくなるんじゃね

**デフォルトの名無しさん** · 2017/06/21(水) 11:13:54.44

>>902
コンストラクタはクラス名と同じって制約があるんだから、コンパイラの気持ちになったらnewなんて別にあってもなくてもいいでしょ
人にわかりやすいようにしてあるだけ
なにがコンパイラの気持ちだアホ

**デフォルトの名無しさん** · 2017/06/21(水) 11:19:25.58

パラメーターがないとややこしいからある場合で考えると
(new Foo)(p1,p2,p3) ととらえるか、new (Foo(p1,p2,p3)) と捉えるかの感覚の違いじゃない？
前者なら宣言的に「新しくFooのインスタンスを作って（初期化パラメーター渡して）るんだな」感が出てnewはあったほうがいいし、
後者なら「新しいFooのインスタンスを作る関数のFoo()を呼んでるのにnewなんて余計やろ？」ってなる

従ってコンストラクタとしてFooを定義する言語や、クラスがそもそも関数的な存在の言語ならnewは蛇足

**デフォルトの名無しさん** · 2017/06/21(水) 11:39:01.69

>>902
コンパイラとしては無いと困るもんでもない
newのあるなしで挙動は変えられるけど

**デフォルトの名無しさん** · 2017/06/21(水) 11:42:21.94

スタックかヒープかってこと？

**デフォルトの名無しさん** · 2017/06/21(水) 11:46:29.64

>>908
> コンストラクタはクラス名と同じって制約があるんだから、コンパイラの気持ちになったらnewなんて別にあってもなくてもいいでしょ
class Foo { }
function Foo() { }

**デフォルトの名無しさん** · 2017/06/21(水) 11:48:18.80

class Foo { }
function Foo() { }
が両立する言語の場合、
a = new Foo(); // Fooクラスのコンストラクタ
b = Foo(); // 関数Fooの呼び出し
を区別する必要があるから、newが必要

**デフォルトの名無しさん** · 2017/06/21(水) 12:29:16.70

>>913
それをnew無しにもできるでしょ。クラスと関数で区別つくんだし

**デフォルトの名無しさん** · 2017/06/21(水) 12:43:42.22

>>903
リフレクション

**デフォルトの名無しさん** · 2017/06/21(水) 12:45:39.84

Activator.CreateInstance()とかは？

**デフォルトの名無しさん** · 2017/06/21(水) 12:52:24.42

classname.new()

**デフォルトの名無しさん** · 2017/06/21(水) 12:56:10.63

>>914
newなしだったら、
a = Foo();
b = Foo();
なんですが・・・

**デフォルトの名無しさん** · 2017/06/21(水) 14:21:56.72

new を付けなかったら、インスタンスが作られないから、
this が正しく、インスタンスを指さない

JavaScript だと、prototype 継承が動作しない

**デフォルトの名無しさん** · 2017/06/21(水) 16:12:32.59

お、おう

**デフォルトの名無しさん** · 2017/06/21(水) 22:04:39.36

JavaScriptができた当時の仕様だと、
インスタンスを作る方法はnewしかないでしょ？