前スレ
オブジェクト指向って自然な文法だな 2
http://echo.2ch.net/test/read.cgi/tech/1490506257/
探検
オブジェクト指向って自然な文法だな 3 [無断転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
2017/04/02(日) 16:30:38.65ID:n7h/bBRg
871デフォルトの名無しさん
2017/06/19(月) 01:19:07.10ID:JcFW0m+v https://ja.wikipedia.org/wiki/Simula
Simula 67 ではオブジェクト、 クラス、サブクラス、継承、動的束縛(仮想関数)、
コルーチン、 ディスクリートイベントシミュレーション、ガベージコレクションの機能をもち、
オブジェクト指向プログラミングの基本概念はすべてここで発案されているといえる。
Simula はプログラミングパラダイムとして最初のオブジェクト指向言語であると考えられる。
その名前が示すように Simula はシミュレーションを行うために設計され、
その必要性から今日のオブジェクト指向言語で使われる多くの機能のためのフレームワークを提供した。
なお、Simula 当時「オブジェクト指向」という言葉はまだない。
この用語はアラン・ケイが Simula の概念として70年代ごろに使い出したのが始まりといわれている。
従ってその意味では Simula が世界最初のオブジェクト指向言語であり、
Simula は「オブジェクト指向として再認識が可能な最古の言語」ということができる。
Simula 67 ではオブジェクト、 クラス、サブクラス、継承、動的束縛(仮想関数)、
コルーチン、 ディスクリートイベントシミュレーション、ガベージコレクションの機能をもち、
オブジェクト指向プログラミングの基本概念はすべてここで発案されているといえる。
Simula はプログラミングパラダイムとして最初のオブジェクト指向言語であると考えられる。
その名前が示すように Simula はシミュレーションを行うために設計され、
その必要性から今日のオブジェクト指向言語で使われる多くの機能のためのフレームワークを提供した。
なお、Simula 当時「オブジェクト指向」という言葉はまだない。
この用語はアラン・ケイが Simula の概念として70年代ごろに使い出したのが始まりといわれている。
従ってその意味では Simula が世界最初のオブジェクト指向言語であり、
Simula は「オブジェクト指向として再認識が可能な最古の言語」ということができる。
872デフォルトの名無しさん
2017/06/19(月) 01:25:04.44ID:l1liGy+g873デフォルトの名無しさん
2017/06/19(月) 01:27:16.04ID:l1liGy+g 志村 けんは、日本のコメディアン、お笑いタレント、司会者。ザ・ドリフターズのメンバー。
生年月日: 1950年2月20日 (67歳)
https://ja.wikipedia.org/wiki/Simula
志村(67) ではオブジェクト、 クラス、サブクラス、継承、動的束縛(仮想関数)、
コルーチン、 ディスクリートイベントシミュレーション、ガベージコレクションの機能をもち、
オブジェクト指向プログラミングの基本概念はすべてここで発案されているといえる。
志村 はプログラミングパラダイムとして最初のオブジェクト指向言語であると考えられる。
その名前が示すように 志村 はシミュレーションを行うために設計され、
その必要性から今日のオブジェクト指向言語で使われる多くの機能のためのフレームワークを提供した。
なお、志村 当時「オブジェクト指向」という言葉はまだない。
この用語は 荒井・注 が 志村 の概念として70年代ごろに使い出したのが始まりといわれている。
従ってその意味では 志村 が世界最初のオブジェクト指向言語であり、
志村 は「オブジェクト指向として再認識が可能な最古の言語」ということができる。
生年月日: 1950年2月20日 (67歳)
https://ja.wikipedia.org/wiki/Simula
志村(67) ではオブジェクト、 クラス、サブクラス、継承、動的束縛(仮想関数)、
コルーチン、 ディスクリートイベントシミュレーション、ガベージコレクションの機能をもち、
オブジェクト指向プログラミングの基本概念はすべてここで発案されているといえる。
志村 はプログラミングパラダイムとして最初のオブジェクト指向言語であると考えられる。
その名前が示すように 志村 はシミュレーションを行うために設計され、
その必要性から今日のオブジェクト指向言語で使われる多くの機能のためのフレームワークを提供した。
なお、志村 当時「オブジェクト指向」という言葉はまだない。
この用語は 荒井・注 が 志村 の概念として70年代ごろに使い出したのが始まりといわれている。
従ってその意味では 志村 が世界最初のオブジェクト指向言語であり、
志村 は「オブジェクト指向として再認識が可能な最古の言語」ということができる。
874デフォルトの名無しさん
2017/06/19(月) 01:28:38.27ID:l1liGy+g875デフォルトの名無しさん
2017/06/19(月) 01:44:56.66ID:9pZo4esm >>871
毎回思ってることだけど、アランケイのオブジェクト指向のポイントは
むしろメッセージセンドでオブジェクトに命令を送るという方式の発案なので
(さらにいうと、インスタンスを作るのにクラスそのものに「複製を作れ」と命令して作らせる
言語システム(予約語)から離れてクラスが自律的に動く思想の方)
Simulaはかなり毛色の違うオブジェクト指向だし
言ってしまうとこれがカンチガイされたままオブジェクト指向だと思われた結果
C++というそびえ立つクソの山が産まれて業界を何十年も混乱に陥れた元凶だから
Simula持ってきて「オブジェクト指向とは〜」ってやった瞬間
お話にならないぐらいオブジェクト指向を理解していないバカが来た。
で話が終わるんだけど。
毎回思ってることだけど、アランケイのオブジェクト指向のポイントは
むしろメッセージセンドでオブジェクトに命令を送るという方式の発案なので
(さらにいうと、インスタンスを作るのにクラスそのものに「複製を作れ」と命令して作らせる
言語システム(予約語)から離れてクラスが自律的に動く思想の方)
Simulaはかなり毛色の違うオブジェクト指向だし
言ってしまうとこれがカンチガイされたままオブジェクト指向だと思われた結果
C++というそびえ立つクソの山が産まれて業界を何十年も混乱に陥れた元凶だから
Simula持ってきて「オブジェクト指向とは〜」ってやった瞬間
お話にならないぐらいオブジェクト指向を理解していないバカが来た。
で話が終わるんだけど。
876デフォルトの名無しさん
2017/06/19(月) 01:57:02.13ID:l1liGy+g そういやエージェント指向ってどうなんたんかな?
昔、15年ぐらい前に学生だった時に先生がこれからはエージェント指向だって言ってたんだが
その説明きいて、俺はそれってオブジェクト指向+メタデータじゃね?程度に思ってた。
オブジェクトが自律的に仕事をする。みたいな事を言ってたんだが、
それを実現するにはどんな要望であっても、それを実現するためのモジュールが存在し
その要望を完璧に判断してモジュールを選択できるAIでも搭載してなきゃできないような
ものだったのでエージェント指向でもなんでもないし実現は不可能と思っていたが。
まあエージェント指向とやらにはさっさと見切りをつけたので
俺が間違って理解してるんだと思うけどねw
でも事実としてオブジェクト指向を置き換えるものにはならなかったようだね。
昔、15年ぐらい前に学生だった時に先生がこれからはエージェント指向だって言ってたんだが
その説明きいて、俺はそれってオブジェクト指向+メタデータじゃね?程度に思ってた。
オブジェクトが自律的に仕事をする。みたいな事を言ってたんだが、
それを実現するにはどんな要望であっても、それを実現するためのモジュールが存在し
その要望を完璧に判断してモジュールを選択できるAIでも搭載してなきゃできないような
ものだったのでエージェント指向でもなんでもないし実現は不可能と思っていたが。
まあエージェント指向とやらにはさっさと見切りをつけたので
俺が間違って理解してるんだと思うけどねw
でも事実としてオブジェクト指向を置き換えるものにはならなかったようだね。
877デフォルトの名無しさん
2017/06/19(月) 02:06:51.24ID:l1liGy+g >>875
シミュレーションをするために言語を作ったけど、
本来の用途としてはあまり使われず、(よくよく考えてみれば
シミュレーションなんてそんなにするか?ってことなんだろう)
副産物として生まれてオブジェクト指向の技術の基礎とでも
呼べるようなものが独立しそれが洗練されてオブジェクト指向言語
として生まれ変わったってことなんかね。
UMLも似たようなもんだよね。元々はオブジェクト指向分析や設計の方法を
色んな人が考えていたけど、それぞれを比較検討する時、それぞれで図の書き方が
異なっていたので、分析や設計方法が色々あるのはわかる。だけどせめて図の書き方
ぐらいは統一しようじゃないかって生まれたもの。
でもオブジェクト指向の分析や設計方法はみんな飽きてしまったのか話題にならなくなり
UMLという図の書き方だけが広まったと。
シミュレーションをするために言語を作ったけど、
本来の用途としてはあまり使われず、(よくよく考えてみれば
シミュレーションなんてそんなにするか?ってことなんだろう)
副産物として生まれてオブジェクト指向の技術の基礎とでも
呼べるようなものが独立しそれが洗練されてオブジェクト指向言語
として生まれ変わったってことなんかね。
UMLも似たようなもんだよね。元々はオブジェクト指向分析や設計の方法を
色んな人が考えていたけど、それぞれを比較検討する時、それぞれで図の書き方が
異なっていたので、分析や設計方法が色々あるのはわかる。だけどせめて図の書き方
ぐらいは統一しようじゃないかって生まれたもの。
でもオブジェクト指向の分析や設計方法はみんな飽きてしまったのか話題にならなくなり
UMLという図の書き方だけが広まったと。
878デフォルトの名無しさん
2017/06/19(月) 08:54:27.70ID:1iazHqgp 歴史的な起源に拘らない人と、
「もともとはこうだったのに変質してしまった。クソが!」と思う人がいるのだなあ。
と感じました、まる
「もともとはこうだったのに変質してしまった。クソが!」と思う人がいるのだなあ。
と感じました、まる
879デフォルトの名無しさん
2017/06/19(月) 10:38:29.48ID:MTmJn+ZD 歴史的な起源に拘らないとsmalltalkerなんてやってられないよ
880デフォルトの名無しさん
2017/06/19(月) 11:06:11.95ID:j3p5BJjc ストラウストラップとケイの“オブジェクト指向”は別物なので混同せずちゃんと区別したほうがよい
ストラウストラップの“オブジェクト指向”は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
ちなみにアクター理論はこのアイデアを実行時の並行性に応用し定式化を試みたもの
ストラウストラップの“オブジェクト指向”は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
ちなみにアクター理論はこのアイデアを実行時の並行性に応用し定式化を試みたもの
881デフォルトの名無しさん
2017/06/19(月) 11:42:12.84ID:1iazHqgp 実用的な言語の話をしている
882デフォルトの名無しさん
2017/06/19(月) 16:38:13.20ID:LZvrLoRE 決定の遅延とは即ち実行時に決定するということ
つまりデータと処理の抽象化を徹底するということだ
つまりデータと処理の抽象化を徹底するということだ
883デフォルトの名無しさん
2017/06/19(月) 16:49:21.59ID:LZvrLoRE データの抽象化を徹底すると型とクラスが無くなる
型によってデータ長も処理の方法も変わるのが煩雑さの根源だ
型によってデータ長も処理の方法も変わるのが煩雑さの根源だ
884デフォルトの名無しさん
2017/06/19(月) 19:55:43.12ID:/Mgza80D もともと、コンピュータが巨大にそしてネットワークで接続されると
離れたユニットに「この処理をお願いします」と頼むことになって
シーケンシャルな処理待ちしていたらコンピュータが止まっちゃうし
周りの環境も実行時に刻々と変化してゆくから
オブジェクトにはある種の他と切り離された自律性がいるよね。なのに
なぜか21世紀のインターネット時代に「いいや!カッチリ制御して
他に影響が出ないように書ければこの『世界が勝手に変化するバグ』は排除できるはずだ!」
という謎のカルトが一部で流行り出してるのがどうにもよくわからないw
離れたユニットに「この処理をお願いします」と頼むことになって
シーケンシャルな処理待ちしていたらコンピュータが止まっちゃうし
周りの環境も実行時に刻々と変化してゆくから
オブジェクトにはある種の他と切り離された自律性がいるよね。なのに
なぜか21世紀のインターネット時代に「いいや!カッチリ制御して
他に影響が出ないように書ければこの『世界が勝手に変化するバグ』は排除できるはずだ!」
という謎のカルトが一部で流行り出してるのがどうにもよくわからないw
885デフォルトの名無しさん
2017/06/19(月) 21:05:37.05ID:KwjLNCYt ガイジ
886デフォルトの名無しさん
2017/06/19(月) 23:09:44.33ID:g4cBDSU6 歴史的にオブジェクト指向の後にテンプレートとかジェネリックとか言われるのが導入されたけど、継承とかより移譲が重宝されてる辺り、ジェネリックだけで十分じゃね?って気がしなくも無い。
887デフォルトの名無しさん
2017/06/19(月) 23:22:30.80ID:l1liGy+g C++以外にテンプレートがある言語ってあるの?
C++のテンプレートは本来ジェネリック程度の機能で良かったのに
ちょっと道を外したら、意外と高度なことができることが分かっちゃって
本来の目的から大きくはずれてコンパイル時コードジェネレータみたいな
もんになっちゃったでしょ?
C++のテンプレートは本来ジェネリック程度の機能で良かったのに
ちょっと道を外したら、意外と高度なことができることが分かっちゃって
本来の目的から大きくはずれてコンパイル時コードジェネレータみたいな
もんになっちゃったでしょ?
888デフォルトの名無しさん
2017/06/19(月) 23:28:36.65ID:+dhODesl そもそも継承なんてものの80%はゴミ
protcolとdelegateこそが至高
protcolとdelegateこそが至高
889デフォルトの名無しさん
2017/06/19(月) 23:30:58.96ID:9w3QFpXl そういのいいんで
890デフォルトの名無しさん
2017/06/19(月) 23:33:07.34ID:xaFoAOZp そういやこの1スレたてたガイジ最近みないね
891デフォルトの名無しさん
2017/06/20(火) 23:04:56.68ID:v+vDltnD 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
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
892デフォルトの名無しさん
2017/06/20(火) 23:05:26.93ID:v+vDltnD 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:
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:
893デフォルトの名無しさん
2017/06/20(火) 23:52:17.95ID:pEbbmUs5 だからそういうのはブログで……
894デフォルトの名無しさん
2017/06/21(水) 00:42:37.70ID:Mt9AmAoV ん。
だってオブジェクト指向言語使ってた時って、ここまで似たようなコード書かなくて良いくらいライブラリ化出来たことなかったんだもん。
だってオブジェクト指向言語使ってた時って、ここまで似たようなコード書かなくて良いくらいライブラリ化出来たことなかったんだもん。
895デフォルトの名無しさん
2017/06/21(水) 00:55:18.54ID:nYB1lvTl readFileの中身が謎だらけで怖くて使えない
896デフォルトの名無しさん
2017/06/21(水) 01:08:07.93ID:Mt9AmAoV PythonやRubyのopenと大差ないと思うが。。。
嫌ならもっと低レベルの関数もあるよ?
嫌ならもっと低レベルの関数もあるよ?
897デフォルトの名無しさん
2017/06/21(水) 07:06:46.09ID:nYB1lvTl 型クラスの仕組みが姑息
LISPのSETFと同じくらいガッカリ感ある
LISPのSETFと同じくらいガッカリ感ある
898デフォルトの名無しさん
2017/06/21(水) 07:08:04.36ID:n4ESO8N1 猫ドアは後出しでドアの要件増やされるけどインターフェイスで振る舞いを追加してけば対応可能じゃないの
オブジェクト指向言語的に考えたら
オブジェクト指向言語的に考えたら
899デフォルトの名無しさん
2017/06/21(水) 08:08:08.40ID:XUERnIj3 >>898
それはインタフェース自体を増やすと言ってるように聞こえるけど?
それはインタフェース自体を増やすと言ってるように聞こえるけど?
900デフォルトの名無しさん
2017/06/21(水) 08:31:13.44ID:ajPkQF0E >>898は新規インターフェイスの追加じゃなくて既存のインターフェイスへ機能追加だろ
901デフォルトの名無しさん
2017/06/21(水) 08:32:01.05ID:S2UygZ3z new ってなんなのか、なぜ必要なのか教えて、
オブジェクト生成元クラスのコンストラクタ関数の結果を得るだけなら、
Foo obj = Foo();
とすれば new なくても書けるのに、なぜ new を書く必要があるの?
オブジェクト生成元クラスのコンストラクタ関数の結果を得るだけなら、
Foo obj = Foo();
とすれば new なくても書けるのに、なぜ new を書く必要があるの?
902デフォルトの名無しさん
2017/06/21(水) 08:55:18.55ID:BZXMZb7j newがあるから僕らはそれがコンストラクタを呼ぶものだと知ることができる
newがなければ何をすれば良いのかわからない
コンパイラの気持ちになって考えろよ
newがなければ何をすれば良いのかわからない
コンパイラの気持ちになって考えろよ
903デフォルトの名無しさん
2017/06/21(水) 09:09:53.08ID:mDRh5T94 newをかかなくていい言語をさがそう
904デフォルトの名無しさん
2017/06/21(水) 09:11:42.85ID:mDRh5T94 C++の例
Base *base_pointer = new Base();
Base base();
Base *base_pointer = new Base();
Base base();
905デフォルトの名無しさん
2017/06/21(水) 09:19:49.52ID:mDRh5T94 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
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
906デフォルトの名無しさん
2017/06/21(水) 10:28:20.88ID:bqAd0GFb new要らないな
907デフォルトの名無しさん
2017/06/21(水) 10:47:23.25ID:eLmte6hp コンパイラが進化すればいらなくなるんじゃね
908デフォルトの名無しさん
2017/06/21(水) 11:13:54.44ID:+MSTc8BP >>902
コンストラクタはクラス名と同じって制約があるんだから、コンパイラの気持ちになったらnewなんて別にあってもなくてもいいでしょ
人にわかりやすいようにしてあるだけ
なにがコンパイラの気持ちだアホ
コンストラクタはクラス名と同じって制約があるんだから、コンパイラの気持ちになったらnewなんて別にあってもなくてもいいでしょ
人にわかりやすいようにしてあるだけ
なにがコンパイラの気持ちだアホ
909デフォルトの名無しさん
2017/06/21(水) 11:19:25.58ID:ooAgeRH5 パラメーターがないとややこしいからある場合で考えると
(new Foo)(p1,p2,p3) ととらえるか、new (Foo(p1,p2,p3)) と捉えるかの感覚の違いじゃない?
前者なら宣言的に「新しくFooのインスタンスを作って(初期化パラメーター渡して)るんだな」感が出てnewはあったほうがいいし、
後者なら「新しいFooのインスタンスを作る関数のFoo()を呼んでるのにnewなんて余計やろ?」ってなる
従ってコンストラクタとしてFooを定義する言語や、クラスがそもそも関数的な存在の言語ならnewは蛇足
(new Foo)(p1,p2,p3) ととらえるか、new (Foo(p1,p2,p3)) と捉えるかの感覚の違いじゃない?
前者なら宣言的に「新しくFooのインスタンスを作って(初期化パラメーター渡して)るんだな」感が出てnewはあったほうがいいし、
後者なら「新しいFooのインスタンスを作る関数のFoo()を呼んでるのにnewなんて余計やろ?」ってなる
従ってコンストラクタとしてFooを定義する言語や、クラスがそもそも関数的な存在の言語ならnewは蛇足
910デフォルトの名無しさん
2017/06/21(水) 11:39:01.69ID:XUERnIj3911デフォルトの名無しさん
2017/06/21(水) 11:42:21.94ID:x++JJuQ3 スタックかヒープかってこと?
912デフォルトの名無しさん
2017/06/21(水) 11:46:29.64ID:v7daEmTS >>908
> コンストラクタはクラス名と同じって制約があるんだから、コンパイラの気持ちになったらnewなんて別にあってもなくてもいいでしょ
class Foo { }
function Foo() { }
> コンストラクタはクラス名と同じって制約があるんだから、コンパイラの気持ちになったらnewなんて別にあってもなくてもいいでしょ
class Foo { }
function Foo() { }
913デフォルトの名無しさん
2017/06/21(水) 11:48:18.80ID:v7daEmTS class Foo { }
function Foo() { }
が両立する言語の場合、
a = new Foo(); // Fooクラスのコンストラクタ
b = Foo(); // 関数Fooの呼び出し
を区別する必要があるから、newが必要
function Foo() { }
が両立する言語の場合、
a = new Foo(); // Fooクラスのコンストラクタ
b = Foo(); // 関数Fooの呼び出し
を区別する必要があるから、newが必要
914デフォルトの名無しさん
2017/06/21(水) 12:29:16.70ID:Y4WM7moX >>913
それをnew無しにもできるでしょ。クラスと関数で区別つくんだし
それをnew無しにもできるでしょ。クラスと関数で区別つくんだし
915デフォルトの名無しさん
2017/06/21(水) 12:43:42.22ID:Y9QahJfp >>903
リフレクション
リフレクション
916デフォルトの名無しさん
2017/06/21(水) 12:45:39.84ID:Y9QahJfp Activator.CreateInstance()とかは?
917デフォルトの名無しさん
2017/06/21(水) 12:52:24.42ID:JHIJAiI6 classname.new()
918デフォルトの名無しさん
2017/06/21(水) 12:56:10.63ID:v7daEmTS919デフォルトの名無しさん
2017/06/21(水) 14:21:56.72ID:L1LFWazB new を付けなかったら、インスタンスが作られないから、
this が正しく、インスタンスを指さない
JavaScript だと、prototype 継承が動作しない
this が正しく、インスタンスを指さない
JavaScript だと、prototype 継承が動作しない
920デフォルトの名無しさん
2017/06/21(水) 16:12:32.59ID:CwIOTiNS お、おう
921デフォルトの名無しさん
2017/06/21(水) 22:04:39.36ID:xiNpcjp1 JavaScriptができた当時の仕様だと、
インスタンスを作る方法はnewしかないでしょ?
インスタンスを作る方法はnewしかないでしょ?
922デフォルトの名無しさん
2017/07/01(土) 23:37:05.45ID:Tp0p2tiJ まぁ言ってる意味は分からんでもないんだよな
コンパイラはFooがクラスか関数か、何なのか知ってるから
区別できるよねっていう
ただし意味解析をしなければFooが何なのか分からない
newがあれば構文解析だけで何をしようとしているかわかる
Fooが何かのか解析するまでもなく、字面の並びだけで関数呼び出しなのか
インスタンスの生成なのかの区別がつく
いざコンパイラを作るとなったらこの差はでかい
あとなんつーか、そういうこと言い出したら
(int i = 0; i < 100; ++i ) なんていう並びの書き方はfor文の時にしか使わないんだから
「for」って要らなくね?とか、goto ERR;って書くけど、ERRがラベルであることは
コンパイラは知っているんだから「goto」って要らなくね?とか
コンパイラはFooがクラスか関数か、何なのか知ってるから
区別できるよねっていう
ただし意味解析をしなければFooが何なのか分からない
newがあれば構文解析だけで何をしようとしているかわかる
Fooが何かのか解析するまでもなく、字面の並びだけで関数呼び出しなのか
インスタンスの生成なのかの区別がつく
いざコンパイラを作るとなったらこの差はでかい
あとなんつーか、そういうこと言い出したら
(int i = 0; i < 100; ++i ) なんていう並びの書き方はfor文の時にしか使わないんだから
「for」って要らなくね?とか、goto ERR;って書くけど、ERRがラベルであることは
コンパイラは知っているんだから「goto」って要らなくね?とか
923デフォルトの名無しさん
2017/07/01(土) 23:45:05.96ID:N+ZXroXE Foo()というメソッドが定義されてなければnewなしだとコンパイルエラーになるんじゃないの...
924デフォルトの名無しさん
2017/07/02(日) 00:07:24.31ID:yqVk05l0 コンパイラはソフトウェアにとって重要なものであるので
ちゃんと専門の学問があってセオリーがある
必ずしもセオリー通りにする必要はないが、いちおうセオリーがある
セオリーに従えばコンパイラは
字句解析→構文解析→意味解析、というステップを踏んで
プログラムを解析することになっている
ここで、Fooがクラスであるか関数であるかによって
インスタンス生成か関数呼び出しか、切り替えるという文法にしてしまうと
意味解析をしなければ構文解析ができない、という逆流現象が発生してしまう
また、コンパイラ生成器にBNFか何かを食わして自動で構文解析のコードを生成してもらうと
思っても、意味解析をしなければ構文が判明しない箇所のある文法では都合が悪いじゃろ
ただし、セオリーはセオリーでしかなく、従わないことも多々ある
たとえばC++の字句解析において、これは最長一致であるので
「>>」は右シフトと判断されそうなものであるが
出現場所によっては「>」と「>」の二つに分解される
これは字句解析がその後の工程であるはずの構文解析を先回りして少しだけ
してしまっている状態
ちゃんと専門の学問があってセオリーがある
必ずしもセオリー通りにする必要はないが、いちおうセオリーがある
セオリーに従えばコンパイラは
字句解析→構文解析→意味解析、というステップを踏んで
プログラムを解析することになっている
ここで、Fooがクラスであるか関数であるかによって
インスタンス生成か関数呼び出しか、切り替えるという文法にしてしまうと
意味解析をしなければ構文解析ができない、という逆流現象が発生してしまう
また、コンパイラ生成器にBNFか何かを食わして自動で構文解析のコードを生成してもらうと
思っても、意味解析をしなければ構文が判明しない箇所のある文法では都合が悪いじゃろ
ただし、セオリーはセオリーでしかなく、従わないことも多々ある
たとえばC++の字句解析において、これは最長一致であるので
「>>」は右シフトと判断されそうなものであるが
出現場所によっては「>」と「>」の二つに分解される
これは字句解析がその後の工程であるはずの構文解析を先回りして少しだけ
してしまっている状態
925デフォルトの名無しさん
2017/07/02(日) 00:07:47.85ID:0SO6fajC926デフォルトの名無しさん
2017/07/02(日) 00:11:14.19ID:0SO6fajC なんかニワカが長文書いているようだが、
JavaScriptにclassキーワードが追加されたのは比較的最近。
互換性を保つ上で、classキーワードは関数に変換される。
また
function Klass と書けばクラス
function func と書けば関数
というふうに先頭が大文字か小文字かで区別する
というのはあるがこれは慣習であって言語仕様ではない。
JavaScriptにclassキーワードが追加されたのは比較的最近。
互換性を保つ上で、classキーワードは関数に変換される。
また
function Klass と書けばクラス
function func と書けば関数
というふうに先頭が大文字か小文字かで区別する
というのはあるがこれは慣習であって言語仕様ではない。
927デフォルトの名無しさん
2017/07/02(日) 00:14:28.75ID:yqVk05l0928デフォルトの名無しさん
2017/07/02(日) 01:37:38.04ID:9byBa7OY obj = instantiate(Foo)
929デフォルトの名無しさん
2017/07/03(月) 06:49:00.62ID:rdvbpUW5 オブジェクトが請け負う役割の範囲が未だよく分からん。
例えば、武器を装備するという行為は、
オブジェクト自身に機能を持たせるのか、
actorを第一引数とする処理を別に作るのか。
対象を省略できるからオブジェクトに実装したりするけど、コンテキストの依存性などの問題でゲームマスター的なクラスに処理を任せるべきだなと思ったり。
例えば、武器を装備するという行為は、
オブジェクト自身に機能を持たせるのか、
actorを第一引数とする処理を別に作るのか。
対象を省略できるからオブジェクトに実装したりするけど、コンテキストの依存性などの問題でゲームマスター的なクラスに処理を任せるべきだなと思ったり。
930デフォルトの名無しさん
2017/07/03(月) 07:34:00.67ID:Rzh0OD1D 「武器を装備しろ」と命令したらあとは当該クラスがよしなにやって
こっちには結果教えてくれればいいだけなので
その「役割の範囲」そのものが当該クラス任せです。
クラスが自分でやっても、武器総合管理クラスに聞いてても
上位は感知しないことで切り離してるので。
こっちには結果教えてくれればいいだけなので
その「役割の範囲」そのものが当該クラス任せです。
クラスが自分でやっても、武器総合管理クラスに聞いてても
上位は感知しないことで切り離してるので。
931デフォルトの名無しさん
2017/07/03(月) 07:39:44.51ID:sUmj13cM equip(soldier, weapon)
soldier.equip(weapon)
soldier.equip(weapon)
932デフォルトの名無しさん
2017/07/03(月) 11:04:22.70ID:SlrShd+d 関数型なら武器を装備するのも簡単
933デフォルトの名無しさん
2017/07/03(月) 22:50:46.43ID:R6Sojlsl セックスはどうすればいいんだ?
934デフォルトの名無しさん
2017/07/03(月) 23:00:58.77ID:c364q6zP chinko.equip(manko)
935デフォルトの名無しさん
2017/07/03(月) 23:03:36.07ID:R6Sojlsl 一方的だな
936デフォルトの名無しさん
2017/07/04(火) 23:07:51.12ID:VgVQ93XC friendにして相互っつ〜ワケにはいかんの?
937デフォルトの名無しさん
2017/07/05(水) 21:55:54.95ID:QXr7Yy+H オブジェクト試行の「オブジェクト」っていうネーミングって
誤解を招かないか、
どっちかというと「モノ」じゃなくて仮想的な「生命体」じゃない?
だって動きを持ってるし、誕生して活動して死ぬわけじゃん。
「モノ」なのはコンストラクタやメソッドでやり取りされる「引数」
の方だろ。
「プロパティ」は「生命体の所有物」だと思えばスッキリする。
なのに生命体の方をオブジェクトと言うのはおかしいよ。
クラスはその生命体の「家系」みたいなもんだな。
両親がいる必要がないから単細胞生物の分裂のほうが近いか、
クラスは「遺伝子情報」だな、これでかなりスッキリするじゃないか。
誤解を招かないか、
どっちかというと「モノ」じゃなくて仮想的な「生命体」じゃない?
だって動きを持ってるし、誕生して活動して死ぬわけじゃん。
「モノ」なのはコンストラクタやメソッドでやり取りされる「引数」
の方だろ。
「プロパティ」は「生命体の所有物」だと思えばスッキリする。
なのに生命体の方をオブジェクトと言うのはおかしいよ。
クラスはその生命体の「家系」みたいなもんだな。
両親がいる必要がないから単細胞生物の分裂のほうが近いか、
クラスは「遺伝子情報」だな、これでかなりスッキリするじゃないか。
938デフォルトの名無しさん
2017/07/05(水) 22:12:07.95ID:odMt6Ynp つまり美少女の母親もまた処女懐胎した美少女なわけだな
939デフォルトの名無しさん
2017/07/05(水) 23:48:29.76ID:s7u8/Pz4 まだいたの?
オブジェクトを無理やり現実に当てはめるやつ
オブジェクトを無理やり現実に当てはめるやつ
940デフォルトの名無しさん
2017/07/06(木) 00:07:02.68ID:/frq9FD5 >>939
生温く見守ろうぜ
生温く見守ろうぜ
941デフォルトの名無しさん
2017/07/06(木) 00:22:32.98ID:O802MHgz942デフォルトの名無しさん
2017/07/06(木) 01:33:28.30ID:Gh9vN0mU 擬人化しないと物事を理解できない人っているよな
943デフォルトの名無しさん
2017/07/06(木) 01:40:25.53ID:9sJW4q9K じゃああなた方はバイナリの0と1をCPUの信号レベルで
全部機械的に把握できるんだな?すげえなぁ、さすが
コンピュータの熟練技術者は違うね。
言語化してるんだから抽象的思考は重要に決まってんだろ。
全部機械的に把握できるんだな?すげえなぁ、さすが
コンピュータの熟練技術者は違うね。
言語化してるんだから抽象的思考は重要に決まってんだろ。
944デフォルトの名無しさん
2017/07/06(木) 01:53:51.11ID:Gh9vN0mU なに言ってんだこいつ
945デフォルトの名無しさん
2017/07/06(木) 03:07:14.86ID:x/UayICR 抽象化ってなんだっけ?
どこら辺が抽象化してるの?
どこら辺が抽象化してるの?
946デフォルトの名無しさん
2017/07/06(木) 03:11:06.65ID:pIo4ewrq いずれにしても少女に喩えなくて良い
947デフォルトの名無しさん
2017/07/06(木) 04:00:24.80ID:jOp2RAP8 「1+1ってなに?りんごは?りんごはどうなっちゃうの!?」
948デフォルトの名無しさん
2017/07/06(木) 10:41:08.52ID:sqBoBgpD >>947
リンゴは一緒に買いに行ってほしいの
リンゴは一緒に買いに行ってほしいの
949デフォルトの名無しさん
2017/07/06(木) 10:57:30.69ID:/frq9FD5 りんごちゃんかわいい
950デフォルトの名無しさん
2017/07/06(木) 11:55:37.04ID:ZZVNNqrh 飛躍的な議論が進行しているな
951デフォルトの名無しさん
2017/07/06(木) 12:23:55.42ID:yrqFUwOI 少しずつまともに美少女うんこ問題を議論できる土台が出来てきたようだな
952デフォルトの名無しさん
2017/07/06(木) 12:27:47.00ID:jsnas7L+ 何を面白がるかみたなもんにこそ知性が出ちゃうと思ってる
悲しいね
自覚が無いのか意固地になっちゃってるのか知らんけど
悲しいね
自覚が無いのか意固地になっちゃってるのか知らんけど
953デフォルトの名無しさん
2017/07/06(木) 18:21:22.89ID:j+3WJv+Z モデルは問題解決のために設計するので、
まったく的外れ。
世の中を表現したいわけじゃないし、
世の中に似せる必要も全くない。
まったく的外れ。
世の中を表現したいわけじゃないし、
世の中に似せる必要も全くない。
954デフォルトの名無しさん
2017/07/06(木) 19:22:23.33ID:0T2UvbzF なんか最近「モデル」って言うの馬鹿の間で流行ってるの?w
955デフォルトの名無しさん
2017/07/06(木) 19:24:13.39ID:NwSzXY2t (? なに言ってんだこいつ…)
956デフォルトの名無しさん
2017/07/06(木) 19:40:14.63ID:rLOZYnLv オブジェクト指向ってDBのエンティティを拡張したものだろ
1事実1箇所と考えたら現実に当てはめないとダメだろ
1事実1箇所と考えたら現実に当てはめないとダメだろ
957デフォルトの名無しさん
2017/07/06(木) 20:22:03.68ID:ZZVNNqrh958デフォルトの名無しさん
2017/07/06(木) 20:29:21.13ID:Dxq//V42 >>956
残念ながら見当外れ
残念ながら見当外れ
959デフォルトの名無しさん
2017/07/06(木) 20:45:03.97ID:ecitQSu4 エンティティとオブジェクトは対応するものだよ
960デフォルトの名無しさん
2017/07/06(木) 20:47:16.64ID:ecitQSu4 エンティティからクラスを自動生成するのが今のやり方
対応しないとしたら正規化できてない
対応しないとしたら正規化できてない
961デフォルトの名無しさん
2017/07/06(木) 21:08:11.46ID:ZZVNNqrh リソース系ならまだわかるが
962デフォルトの名無しさん
2017/07/06(木) 23:39:48.30ID:x/UayICR 対応と言われても抽象的で分からんな。
エンティティは実態でオブジェクトはその射影だよ。
何を持って対応とするの?
エンティティとオブジェクトで可逆性は保証されてないけど
エンティティは実態でオブジェクトはその射影だよ。
何を持って対応とするの?
エンティティとオブジェクトで可逆性は保証されてないけど
963デフォルトの名無しさん
2017/07/07(金) 00:03:06.17ID:ZLKHtWHA エンティティだけがオブジェクト指向だと思ってるCRUDマンワロタw
964デフォルトの名無しさん
2017/07/07(金) 00:06:20.53ID:ZLKHtWHA そーゆーさ、入れポン出しポンっていうの?超シンプルなCRUDの経験しかない奴が
オブジェクト指向とはをなんぞやを語るのやめてよマジでww
オブジェクト指向とはをなんぞやを語るのやめてよマジでww
965デフォルトの名無しさん
2017/07/07(金) 05:43:32.56ID:1OiH67XQ >>943
何が言いたいのかわからんが、プログラミングしたい事象を、そのままオブジェクトに丸ごと落とし込むんじゃ無くて一旦分解して考える。
共通点とか過去の資産使えそうなのはそうする。
ここは他でも使えそうとかあったら分けておく。
再利用出来そうな場所と、そうでない場所を分ける。
人と車って系統的に全然違うからオブジェクト指向の動物クラスみたいなのじゃ全然違うだろ?
でも移動出来るってのは同じだ。
食事と燃料補給は違うが、エネルギーが無いと動かないってのも同じ。
そうやって全然関係無さそうなものの共通点を考えると抽象的なクラスが出来てくる。
現実のオブジェクトと違うけど、より本質に近いオブジェクトになる。
何が言いたいのかわからんが、プログラミングしたい事象を、そのままオブジェクトに丸ごと落とし込むんじゃ無くて一旦分解して考える。
共通点とか過去の資産使えそうなのはそうする。
ここは他でも使えそうとかあったら分けておく。
再利用出来そうな場所と、そうでない場所を分ける。
人と車って系統的に全然違うからオブジェクト指向の動物クラスみたいなのじゃ全然違うだろ?
でも移動出来るってのは同じだ。
食事と燃料補給は違うが、エネルギーが無いと動かないってのも同じ。
そうやって全然関係無さそうなものの共通点を考えると抽象的なクラスが出来てくる。
現実のオブジェクトと違うけど、より本質に近いオブジェクトになる。
966デフォルトの名無しさん
2017/07/07(金) 07:21:29.95ID:5Fyb0GDQ >>965
人と車を動くという共通点によって同じ操作をインターフェイスで作るみたいな感じ?
10画面程度の業務システムしか組んだことないから知らんのだけど大規模システムはそんな風にオブジェクト指向で設計するの?
オブジェクト指向入門見て分類学的に設計するものだと思ってた
人と車を動くという共通点によって同じ操作をインターフェイスで作るみたいな感じ?
10画面程度の業務システムしか組んだことないから知らんのだけど大規模システムはそんな風にオブジェクト指向で設計するの?
オブジェクト指向入門見て分類学的に設計するものだと思ってた
967デフォルトの名無しさん
2017/07/07(金) 07:25:14.64ID:5Fyb0GDQ 966だけど、ゲームでオブジェクト指向すると動くという操作は人も車も変わらんか
業務システムじゃエンティティが正義だと思うけど、ゲームや制御じゃ事情や適用方法が違うんだろうね
制御は構造化しかやったことないけど
業務システムじゃエンティティが正義だと思うけど、ゲームや制御じゃ事情や適用方法が違うんだろうね
制御は構造化しかやったことないけど
968デフォルトの名無しさん
2017/07/07(金) 07:33:06.32ID:DRnLdr12 >>937
アラン・ケイのメッセージングのオブジェクト指向がまさにその着想だな
http://worrydream.com/EarlyHistoryOfSmalltalk/
My biology major had focused on both cell metabolism and
larger scale morphogenesis with its notions of simple mechanisms
controlling complex processes
でも残念ながら現在の主流は抽象データ型のオブジェクト指向
クラスやそれに準ずる言語機能をユーザー定義型として扱うストラウストラップらの着想が根底にあり
生命体とのアナロジーはそぐわない
アラン・ケイのメッセージングのオブジェクト指向がまさにその着想だな
http://worrydream.com/EarlyHistoryOfSmalltalk/
My biology major had focused on both cell metabolism and
larger scale morphogenesis with its notions of simple mechanisms
controlling complex processes
でも残念ながら現在の主流は抽象データ型のオブジェクト指向
クラスやそれに準ずる言語機能をユーザー定義型として扱うストラウストラップらの着想が根底にあり
生命体とのアナロジーはそぐわない
969デフォルトの名無しさん
2017/07/07(金) 07:44:57.59ID:JJYyKRQq 大規模かは知らんが、最近は継承はあまり好まれなくなった。
委譲やインターフェースによる多態性のが好まれる。
これはおいらの推論だが、昔はCUIからGUIに移行するときの規模に対応するためにOOPが誕生した。
今度はPCやスマホなどの多様なGUI、webプログラミングでビューとロジックを分ける必要が出てきた。
ここにOOPは対応しきれてない。
そこで関数型言語が注目されたりした訳だが、今のOOPは関数型言語と同じ所を目指してる最中な気がする。
なぜなら、関数型言語にはコード資産が無いけどOOPには有るから。
全く違うプラットフォーム行くのは怖いから。
実際、言語は優秀でもツール類が絶望的に足りない。
委譲やインターフェースによる多態性のが好まれる。
これはおいらの推論だが、昔はCUIからGUIに移行するときの規模に対応するためにOOPが誕生した。
今度はPCやスマホなどの多様なGUI、webプログラミングでビューとロジックを分ける必要が出てきた。
ここにOOPは対応しきれてない。
そこで関数型言語が注目されたりした訳だが、今のOOPは関数型言語と同じ所を目指してる最中な気がする。
なぜなら、関数型言語にはコード資産が無いけどOOPには有るから。
全く違うプラットフォーム行くのは怖いから。
実際、言語は優秀でもツール類が絶望的に足りない。
970デフォルトの名無しさん
2017/07/07(金) 08:16:46.35ID:G2hd19q1 継承を使わないのは、複雑になるから。
多重で継承すると、デバッグが大変。
継承でロジックの一元化を狙うより、
1番トップの1階層目ぐらいの継承で妥協しておいた方が、
ソースを体系化しやすく、プロジェクトの見通しが良くなる。
多重で継承すると、デバッグが大変。
継承でロジックの一元化を狙うより、
1番トップの1階層目ぐらいの継承で妥協しておいた方が、
ソースを体系化しやすく、プロジェクトの見通しが良くなる。
レス数が950を超えています。1000を超えると書き込みができなくなります。
ニュース
- 【速報】「女芸人No.1決定戦 THE W」9代目女王にニッチェ! 7年ぶり3度目で悲願の優勝 [牛丼★]
- 731部隊の新資料、中国が公開 「日本が細菌戦の罪を自白」と主張 ロシアが引き渡し [少考さん★]
- 中国・ロシア両軍の爆撃機が東京方面へ向かう「異例のルート」を共同飛行…核も搭載可能、連携して威嚇か ★7 [ぐれ★]
- 【芸能】『女芸人No.1決定戦THE W』 粗品が最後にバッサリ「優勝賞金1000万円にしてはレベル低い大会」 [冬月記者★]
- 中国・ロシア両軍の爆撃機が東京方面へ向かう「異例のルート」を共同飛行…核も搭載可能、連携して威嚇か ★8 [ぐれ★]
- 【広島】ペルー女性の国保加入を誤って認め、福山市が医療費484万円を肩代わりするミス…入院して手術を受ける [ぐれ★]
- 【緊急高市朗報】WBC全試合、地上波完全生放送決定wmwmwmwmwmwmwmwmwmwmwmwmwmwmwmw [517459952]
- パン🍞つー✌まる👌見え👊😅👊
- テメェは俺を怒らせたオラァ👊💢😅💢👊🏡
- かなシコ!!許可願います!!
- 🏡パン🍞つー✌まる👌見え👊😅👊
- こち亀初期の麗子って乳放り出してたよな
