[過去ﾛｸﾞ] プログラミングしよう。0x0D (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
450(1): 以下、２０１３年にかわりまして２０１４年がお送りします 2014/01/22(水) 09:35:13.21 ID:KtHCoqNd0(1/4)調 AAS
傍で見ていてわからなかったんでｇｇったが、「仕様書に無い仕様」を量産する為の機能にしか見えない。
実行時型情報ってのは言い得て妙だな。Ｃ＋＋だと実行時型情報はクラスの継承関係だけだったが、それ以外にも（型情報の一種として）メタデーターを与えたり照会したり出来るわけだもんな。
実行時型情報を有効にして、各クラスに型情報保管用クラスを継承（Ｃ＋＋だと多重継承が可能）させれば実装可能か。
でも使う場面が「適当に作っちまったんで矛盾が出ちまったよ何とかしなきゃ」って時ぐらいしか思い付かないし、
Ｃ＋＋とかでは予め準備しておかなきゃ使えないんだからその時には既に意味が無いことになる。
そして予め準備しないで使えるってことは、誰にも予想出来ない場所で謎動作を引き起こせるってことだ。
あ、いや、実行時型情報で型情報保管用クラスを継承しているか否かを確認すれば後から追加しても何とかなるのか。
「メソッドやプロパティーが（プロパティー以外の）メタデーターを持っている」っていう概念に慣れてからじゃないと利便性を把握しづらい機能だなぁ。
旧来的な（＝未分化な）考え方だと、その「メタデーター」ってのはプロパティーなり何なりとして持たせるべき情報だもんな。
それを「持たせることが出来ない型＝ライブラリーとかの既存の変更不能なクラス」と共通して使う為の仕組みなんだから、
即ちツギハギが楽になりツギハギが量産される＝保守やデバッグを困難にする、としか思えないんだよな。
Ｃ＋＋の実行時型情報もそうだけど、どうも「構造化」から離れていっている気がする。
でもオブジェクト指向設計法からは離れていっていないように思う。
やっぱり慣れの問題なのかな。
453(1): 以下、２０１３年にかわりまして２０１４年がお送りします [saga] 2014/01/22(水) 11:06:11.45 ID:j/ZBsBVJo(2/3)調 AAS
C#で属性が採用された最大の理由は、IDEへの情報提供、その次にネイティブとのマーシャリング時の情報提供
もしかしたら優先順位が逆かもしれない
属性の利用法は、典型的には（というか事実上ほぼ唯一）、旧来の
「関数定義→フレームワークにその関数ポインタを登録」
の代替として使い、
「メンバー定義→属性追加→フレームワークがそれを読み取って自動的に登録」
とするためのもの
定義と登録を同じ場所で行えるので、登録漏れを防ぐ事ができる
なので、>>450のような「デバッグを困難にする」という指摘は全く不適切で、逆により簡易にする
強いて言うなら、あまりに簡易になりすぎるので、喜んで不要な場所にも使い始めて爆死する危険があるくらいか
まあ兎に角基本的に、属性はユーザーが定義するものではなく、
フレームワークが定義して、ユーザーが設定し、フレームワークが読み取って利用するもの
まあリフレクション自体がそうなんだから、リフレクションを前提とした属性機能がそうでないわけがないんだが
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.284s*