アカウント名:
パスワード:
> パフォーマンスを重視すると、 > ある程度汚く読みにくくなるのは、 > 仕方がないと思われますが。
これって昔から言われることですが, 本当にこれが当てはまるケースって今ではごく稀になっているのではないかと. おそらくは
程度か, その類似の場合だけで, 多くの場合はむしろコンパイラが最適化しやすいように明瞭なプログラムの流れにした方が良いでしょう. それに手による最適化が必要な局面っ
本質的にはそこまで考えなくともよい、というのが private たる 所以なんですけどね。 Java の限界でしょうか。
ちょっとおっしゃっているMT-Safeな実装がどのようなものか良く分からないので、もう少し解説していただけませんか?
privateな変数にアクセスしにいったら、そのメソッド全体をsynchronized扱いにするとか、そういうことを自動的に扱って欲しいという感じなんでしょうか?
それはいくらなんでもあんまりだ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
どの言語でも (スコア:3, 参考になる)
ある程度汚く読みにくくなるのは、
仕方がないと思われますが。
うちの仕事ものんびりした仕事は少ないので、
とりあえず動くものということだと、
金余分に貰ってそれをOSとDBにつぎ込んで
VBできる人を集めて、ASPで作っちゃいます。
Javaの「使える」エンジニアは常に不足気味ですから、
なかなか現場の要求に迅
Re:どの言語でも (スコア:5, 参考になる)
> パフォーマンスを重視すると、
> ある程度汚く読みにくくなるのは、
> 仕方がないと思われますが。
これって昔から言われることですが, 本当にこれが当てはまるケースって今ではごく稀になっているのではないかと. おそらくは
程度か, その類似の場合だけで, 多くの場合はむしろコンパイラが最適化しやすいように明瞭なプログラムの流れにした方が良いでしょう. それに手による最適化が必要な局面っ
Re:どの言語でも (スコア:1)
そうかな?コンパイラによる最適化が効くような、
抽象度の低い層の話だけでもないだろう。
外部には公開していない、
オブジェクト内部でだけ保持しているような中間状態を利用して
高速化を行うことって多いんでないかな。特に OOP だと。
もちろん、そういう書き方をすると「公開用インターフェース」と
「内部向けインターフェース」の2つが混在するから、
「公開用インターフェース」のみに絞った場合に比べて
読みにくくなる。
後半の部分については同意。
# mishimaは本田透先生を熱烈に応援しています
Re:どの言語でも (スコア:1)
(って言うか、ちょっとしたのならやっちゃうし。
public:はキレイキレイに書くんだけどなぁ。
愚痴
コメントレスなソースとか時々見かけたりして
ソース見ただけで判るからコメント要らないなんて言ってる人とは
一緒に仕事したくありません(タダの愚痴だよ (/_;)
Re:どの言語でも (スコア:0)
Java 文化の場合、
・クラス名、メソッド名、メンバ変数名は省略せずに書く
・1ファイル1クラス
・(特にシステムパッケージ以外の) import はクラス単位で書く
Re:どの言語でも (スコア:0)
> たりともおろそかに扱って欲しくないけどなぁ!
本質的にはそこまで考えなくともよい、というのが private たる
所以なんですけどね。 Java の限界でしょうか。
え、私?
Java は既に見限って C でOOPしてます。
--
iiojun
Re:どの言語でも (スコア:1)
private をおろそかにすると、MT-safe なものはとても書けないはずなんですが。逆に言えば、private をそうとしか考えてないということは、使い方を間違っているとしか言えないような。
Re:どの言語でも (スコア:0)
(というか他とのトレードオフなのかもしれませんが)、
という指摘です。
"private" の意味をよく考えてみましょうね。
Re:どの言語でも (スコア:0)
○ 言語仕様
Re:どの言語でも (スコア:0)
本来、アクセススコープとMT安全性は直交する概念です。
が、「"private"な実装は全て実装者だけ分かっていればよく、
そのクラスの利用者は"public"なインタフェースだけ
気にすればよいのであるから、インタフェースさえしっかり
Re:どの言語でも (スコア:0)
ちょっとおっしゃっているMT-Safeな実装がどのようなものか良く分からないので、もう少し解説していただけませんか?
privateな変数にアクセスしにいったら、そのメソッド全体をsynchronized扱いにするとか、そういうことを自動的に扱って欲しいという感じなんでしょうか?
それはいくらなんでもあんまりだ
Re:どの言語でも (スコア:0)
AC さんのおっしゃられる立場で言うなら、クラスの利用者が Multi Thread 安全性を気にしなくてもすむように、設計者&実装者があらかじめ private なものも含め
Re:どの言語でも (スコア:0)
> context のインスタンスには触れない (特殊なことをすれば触れ
> る)、というような環境なら別ですけどね。でもそれって Thread
> の意味ないっすよね…。
SCOOP [eiffel.com]?
Re:どの言語でも (スコア:1)
で、privateが外部から破壊できる状況ってのは、publicなインターフェースからのアクセスに限られません?
Re:どの言語でも (スコア:0)
実質全て final、ということになりますよね。コンストラクタで指定された属性を保持するだけのメンバ、という感じかな。なんとなく String 型のような「参照専用
Re:どの言語でも (スコア:1)
クラスがMTセーフをうたってないのに、privateはMTセーフであるべきってのは違う話じゃなかろうかと
#単純に参照の出し入れをするだけのセッタとゲッタがあれば private であっても public とかわんねぇじゃんって話の延長ですね
Re:どの言語でも (スコア:0)
あるインスタンスの利用者が、個々の private なメンバについて考慮することは不可能かもしれませんが、そのインスタンスが MT-Safe かどうか、というのは、(private なものも含め) 全ての内部状態への操作に異存する話で、private メンバだけ切り離して考えるわけにはいかないんじゃないでしょうか。
「クラスが MT-Safe をうたっていない」というのは、全 public method が同期されていない
Re:どの言語でも (スコア:1)
たとえば、あるクラスAがあるとして、そのクラスAのprivateなメンバについての情報をソースを参照せずに知る方法はあるでしょうか?(シリアライズの情報を見れば知れる場合も多いけど)通常はわかりませんよね。
その状態でクラスAを利用する人はクラスAがMTセーフかどうかを意識することはあっても、privateなメンバがMTセーフかどうかを意識することはできませんよね。
だから、privateなメンバがMTセーフかどうかを意識しないといけないのはクラスAのpublicなインターフェースの実装者であって、クラスAのユーザではありませんよね。
だから、ユーザはprivateに対してはMTセーフかどうかを考慮はできないし、する必要もないと考えているのですが。
あと、クラスがMTセーフをうたってないといのはドキュメントの話です。MTセーフだと明記されていないクラスはMTセーフでないか、MTセーフかどうかを考慮していないと考えてます。ドキュメントで明記されていなくてもMTセーフなクラスは複数あるかもしれませんが、そのクラスがMTセーフであることはドキュメントに明記されていない以上、約束されたことではなく、次のバージョンでは変わっているかもしれませんし。
外部からMTセーフか否かを知るすべがないのは確かに私も言語の欠陥であると思っています。Javadocの要素でもいいから実装者が外部にMTセーフか否かを公開する方法が欲しいですね(コンパイラでチェックするところまでは求めないけど)。