orange
さんがブースト
やりたいことはわかるし不思議ではないけど、単にそれ以外の選択肢があるし継承が最適解か疑問視されているというだけの話です
ボタンから継承して変なボタン(？)作るの、DelphiのVCLの世界では普通の事だったので、逆に何が不思議なのかわからない＞＜
(あやふやだけどたしかより正確には、直接標準のボタンクラスからどうこうするんじゃなく、VCLは「標準のボタン」クラスの親に各々好きにボタン作る為のボタン抽象クラスみたいなのがあって、それを元に作る感じの構造だったような記憶ある＞＜(あやふや))
限りなくGUI部品の種類が限られるのであれば、バラバラ個別対応でも成り立つかもだけど、種類が多かったり増えたりすればすぐにスパゲティ化するかも＞＜
Windowsでの用語そのまんま使っちゃったからあれだけど、オレンジのその文脈上は GUI部品＝ウィンドウ＞＜
(Windowsの世界ではGUI部品の事をウィンドウって言う＞＜(少なくともプログラミングWindows第5版辺りの時期の用語では))
orange
さんがブースト
「ボタンがウィンドウであるべきでない」と「ボタンもウィンドウも GUI 部品として振る舞うべき」は普通に両立しますよね。
レガシー言語ではそれを継承 (もっと言えば仮想関数テーブル) でしか表現できなかっただけで。
例えばWindowsのウィンドウシステムではボタンもテキスト入力ボックスもウィンドウじゃん？＞＜
見かけ上ツリー状にしたりインタフェース(正しい用語わからない)のような仕組み自体を否定したら「ボタンはウィンドウであるべきではない」みたいな事になるじゃん？＞＜
でも実際にはGUI部品はGUI部品として振る舞って欲しいし、一律で扱える方が都合がいいじゃん？＞＜
日本語おかしかった＞＜；
ていうか、型がツリーになる構造では無くどういう風にGUIツールキットを作る場合ってどうなるのか普通に謎＞＜
orange
さんがブースト
そもそも継承とかいうのだいぶ欠陥が洗い出されてきたので、今更そんな構造にプライマリに依存しないでほしいというのもある
ぐちゃっとしそうではあるし程度の違いはあれだけど、なかに何が入るんだかわかんないし現時点では想定されてない新しいものが入るかも知れず、それは配列かもしれないし子をもつかもしれないみたいな状況、GUIツールキットや簡素なHTMLレンダリングエンジンを作る場面ではそこそこ出てくる場面では？＞＜
orange
さんがブースト
実装すればできるのは本当にその通りだし実際そうする人々もいるんだけど、完全に個人的な観点で趣味としての話をするなら、そんな気合が必要になる時点で敗北ですよ (メンテしたくない)
……まあ FBX で似たようなことやってつらい目に遭ったわけですが
orange
さんがブースト
やればできるのは自明なのでどうでもよくて、向いているか向いていないか、もっと言うと実装の読み書きと利用が快適で無駄がないか否かの話をしています
そのクソみたいな型を作ればできるじゃんって言いたかった・・・＞＜
orange
さんがブースト
あと「String または Link オブジェクトまたは Object オブジェクトまたはそれらの混合配列」みたいなクソみてえな型をネイティブに持っていくのはどう足掻いてもつらい
orange
さんがブースト
いえ普通に困難です
よくわからないままよくわからない事言うけど、オブジェクト指向な方向の言語なら静的な型付けでもこんな感じのデータ扱うの別に困難では無くない？＞＜
- ＠orange_in_space
2017年 4月に登録
