ちゃっぴの監禁部屋

プログラミング言語に制御性を求めるのは間違っているのかな？
ボクは機械語まで手を出す性格だからかもしれないけど、プログラミング言語がより拾い事象を操作する力を得る事を望むピヨ♪
ちゃっぴさんの意見も分からなくはないけど、そもそもアクセスコントロールも出来ない状態は仕様に曖昧さがあると思うし、バイナリの配布問題は今もあるピヨ。
一、オブジェクトがどのようにアクセスされるか
一、オブジェクトに対してどのようなアクセスを期待するのか
一、何時アクセスするのか
一、どこからアクセスするのか
一、親は子へどのようにアクセスされる事を期待しているのか
などの要件はオブジェクト設計の段階で自然と考えている事ピヨ。
これをちゃんと考えておかないと、オブジェクト設計時には想定されなかった子クラスが勝手に継承される事もありえるピヨ。
それにこの手の馬鹿コーディングは頻繁にある事ピヨ。
これを許すのならばセキュリティ上も問題があるピヨ。
だって、勝手にスーパーバイザー的なクラスから継承されても困るもの。
だからといってスーパーバイザー的なクラスを継承禁止にするのも問題が生じるピヨ。
※全ての開発メンバーが信頼できるのかって言うと内部セキュリティを考えるとそうでもない。
他にも保守性の問題があるピヨ。
クラスがどのように利用されるのかを明記しておくのはよい事ピヨ。
いや、逆にそれが明記されていないから保守性に問題が生じているピヨ。
あるクラスがどのようにアクセスされるのかというアクセス特性に着目する事は、そのクラスの定義をより詳細にする事を意味し、それはより深いシステムへの理解を促すから結果としてよいオブジェクト設計が出来ると思うんだ。

とりあえず、前提が違っていると話が噛み合わないので。おいらが問題にしているのはあなたがいうところの

> そのほかにも、セキュリティ技術の向上の為には誰がアクセスできるクラスかなどの情報も不可欠となります

を問題にしています。
現在すでにある public, private 等の access modifiers は問題にしていません。

現在すでにある access modifiers を適切に利用することで、

> これをちゃんと考えておかないと、オブジェクト設計時には想定されなかった子クラスが勝手に継承される事もありえるピヨ。

ような原因で生じる bug を削減することには役に立ちます。

ただし、

> これを許すのならばセキュリティ上も問題があるピヨ

これは直接結びつきません。

>> これを許すのならばセキュリティ上も問題があるピヨ
> これは直接結びつきません。

同意。

セキュリティ云々はオブジェクトを
- どこに置くか
- 誰が触るか
などなど、動的にコロコロ変わる(=変えていい)要因に絡むよね。

ちゃっぴさんの指摘にあるとおり、コロコロ変えていいものをコードに置くもんじゃないでしょ。
変えるたんびにre-compileしたくねー

...って"きっちり"書いてあるのにインドリはばっさりスルーすんの!?
「ひとのはなしをきけー！」 って怒られちゃうよ?

今日も元気だ　ご飯がうまい。

http://d.hatena.ne.jp/busaikuro/20081209#c1231471408

>ちゃっぴさんの指摘にあるとおり、コロコロ変えていいものをコードに置くもんじゃないでしょ。
変えるたんびにre-compileしたくねー


ごめん。書くの忘れていたピヨ。
これについては幾つか考えるところがあるピヨ。
まず書かないのは一番の防御策だと現在はなっているけど、それって技術力不足から生じる問題だと思うピヨ。
その技術的課題を克服するには、コンパイラにより多いメタ情報を与える事により解決可能だと思うピヨ。
それにアクセス要件が変ったときは「仕様も変わっている」場合が多いピヨ。
でもアクセス要件の変更に柔軟であるべきと言うのは同意するピヨ。
でもそれはオブジェクト指向だから何とかできるよね♪
もし出来ない範囲のオブジェクトの変更があるのならばどちみちリファクタリングした方がいいよね♪

そうなると平行線だ。

ちゃっぴさんと僕はそもそもアクセス制御のレイヤが異なり、
言語レベルでどうこうすべきでないと主張しています。
たとえ言語レベルでサポートできる/できたとしてもそれは下策だろうとも考えています。
たとえばCORBAのような分散オブジェクトではオブジェクトがどこにあろうが自由です。要求の変化に応じてお好みの位置に配置できます。
ロード・バランシングなどがその典型例でしょう。
オブジェクトの配置を実行中であれ変更することができます。

たとえ言語レベルでサポートしてくれたとしても、それはOSやネットワーク環境/実行環境にべったり依存したものになるでしょうし、多言語開発となった場合は同様の機能を他言語に強要するでしょう。

加えて処理系およびライブラリも膨れ上がるでしょうね。

おっしゃる事はわかります。が、それは言語だけでなく開発環境/実行環境がトータルにサポートするもので、言語に組み入れるべきとは思いません。

繰り返します。制御のレイヤが異なるのです。

> でもそれはオブジェクト指向だから何とかできるよね♪

オブジェクト指向ならなんとかなるかもしれませんが、
オブジェクト指向"言語"にやらせることに躊躇します。

と、そんなわけで僕は言語でやることじゃないという主張を根拠と共に挙げました。

対してあなたの主張:

> 技術力不足から生じる問題だと思うピヨ。
> メタ情報を与える事により解決可能だと思うピヨ。
> オブジェクト指向だから何とかできるよね♪

これらの根拠が希薄に感じられます。

επιστημηさんの意見はかなり正論だと思うピヨ。
だから全ての言語がそうなるべきだとはボクも思いません。
でもそういう言語があった方がいいとボクは考えています。
それに既にそういう思想は存在します。
Smalltalkが開発環境を含んでいます。
SmalltalkよりもC++が流行っている事も明らかな様に今までの時代は実務的には無理な代物でした。
しかし、検討しなくていいって物でも無いと私は考えます。
昨今のハードウェアの進化はすさまじいものがあります。
そのパワーを開発者の為に使用するという考えはあってもいいのではないでしょうか？
既にいくらかのパワーは悪名高きWindowsUpdateなどのバージョン管理で使用されています。
実例を挙げますと、COMで発生したバージョン管理問題もある程度.NETで解決されました。
そういった技術基盤を賢く開発に利用すれば、今の時代は何とかなると私は思います。


>これらの根拠が希薄に感じられます。

記述不足だったので根拠を書きます。
一、Smalltalkなどの古い技術を応用すれば可能です
一、バージョン管理技術の発達によりそれは可能です
一、データ中心アプローチでデータの安定性が証明されている点に注目してください。確かに安定していないアクセスデータもありますが、安定しているデータもあるはずです。プロセスは変化に弱いのですが、データは安定しております。
一、開発環境の発達により可能です
一、他にも様々な技術を統合すれば可能です。

これらは楽に出来るとは思いません。
でもプログラム言語のパワーアップをどのような手段を用いても図りたいとボクは思います。
お客様の要望は進化しているのに、自分の道具が貧弱ではフアンなのです。
とはいえ、オブジェクト指向が非オブジェクト指向言語でも実現可能なように、今の言語でも工夫すればどうにかなる問題だとは思いますが、平均的なプログラマにそれが可能なのでしょうか？
技術者の実力によっても必要の有無はあるでしょう。
例えば、 επιστημηさんにその様なコンパイラは不要です。C++があれば何とでもなります。
しかし、昨今の技術者の質の低下を考えると楽観視出来ません。
そろそろパワフルな次世代言語を開発するべき次期では無いでしょうか？

セキュリティ階層についてですが、ボクは多層防御の必要性を感じています。
その辺がちゃぴさんと相容れないのかもしれませんが、より一層の多段防御をするほうが良いのではないでしょうか？

> まず書かないのは一番の防御策だと現在はなっているけど、それって技術力不足から生じる問題だと思うピヨ。

そういう問題では無いでしょう。

> その技術的課題を克服するには、コンパイラにより多いメタ情報を与える事により解決可能だと思うピヨ。
> それにアクセス要件が変ったときは「仕様も変わっている」場合が多いピヨ。

Package とかの場合どうするんですか？ 個々の環境に応じて compile し直すのですか？

Configuration file に書くとかもっとまともな意見が出てくるかと思ったんですが、正直意味フメ～です。もっとも、configuration file とか別のものに記述した場合、それをどのように保護して、かつ変更を許可するかを考えなければいけませんけど。

まあ、そうなってくるとすべての application は installer で配布しなきゃならなくなりますね。

OS 側でしくみを用意すれば別ですが。

Access を制御しているように見えても強度は異なる

やばい。えぴさんの問題提起が、日頃のあちきの妄想にぴったんこしていて、しかも炎上してる。
ナイショで断言できないことを、酔っぱらって書いちゃいましょうか。


やっぱ、やめた（笑）
しばらく、冬眠を継続します。ごめんね。
と、ココまで書いて、某所のリンクを見てみました。

パソ通時代、凹んだことが何度かありまして、発言に気を付けてきたつもりだったりします。
でも失敗ばかりですがｗ

えぴさん、偉いなぁ。
としみじみ思いました。

あちきも、仕事から解放されたら、対応してみたいと思う一面です（大謎

> 一、Smalltalkなどの古い技術を応用すれば可能です
> 一、バージョン管理技術の発達によりそれは可能です
> 一、データ中心アプローチでデータの安定性が証明されている点に注目してください。確かに安定していないアクセスデータもありますが、安定しているデータもあるはずです。プロセスは変化に弱いのですが、データは安定しております。
> 一、開発環境の発達により可能です
> 一、他にも様々な技術を統合すれば可能です。

根拠になっていません。ただの言い換えにしか思えません。
具体性のかけらも見えないからです。

「エイズは完治しますか?」
「医学の進歩により可能です」
...これで答になるなら世話ないわ。

# 議論を楽しめそうにないな...そろそろ退くか。

>「エイズは完治しますか?」
「医学の進歩により可能です」
...これで答になるなら世話ないわ。

いえ、既存技術で可能だと言っているので将来の技術ではないですよ。
既存の技術で可能です。
セキュリティデータの変更に対応できないのは技術の問題であって、その問題については解決できる問題だと主張しているのです。
解決できる問題の為に言語の進化を止める必要ないとボクは思います。
不十分な記述かもしれませんが、設計書を書くわけにはいきませんし、可能性を示すだけで十分だと思います。

もしかして皆はアクセス制御リストを考えているのかな？
ボクが言っているのはそういったユーザーのアクセス制御リストのセキュリティではないですよ。
それもある程度考慮するかもしれませんが、コードの信頼性を元に考えるセキュリティなので少し違いますよ。

> セキュリティデータの変更に対応できないのは技術の問題であって、その問題については解決できる問題だと主張しているのです。

誰も理解できませんよ？

> 不十分な記述かもしれませんが、設計書を書くわけにはいきませんし、可能性を示すだけで十分だと思います。

あ、そうですか、はいはい。

> コードの信頼性を元に考えるセキュリティなので少し違いますよ。

その判断基準は何なんですか？ 具体化してください。

あのさぁ、「なぜ理解が得られないか」考えてもらえないかなぁ。

通じてないな、と感じたら抽象レベルを下げるとか
具体例を示すとかたとえ話をするとか、わかってもらう努力しない?
同じことの繰り返し/言い換えじゃ理解してもらえんですよ。
# これって議論/説明のイロハでしょ。

"これで理解できないならお話にならないね"と言い放たれてるように
感じるのですよ。そんな気があるか否かにかかわらず。

# 不安になってきた...僕の書くものにそんなトコはないよね?