【猿が】JavaﾆGenericsﾊ不要 【ｿｰｽ汚す】

だいたい「機能をカプセル化する」事が前提で設計されたクラスとかあってさ、
それで「これは何かを保存する際にそれを線形に保存する」とか「名前による
アクセスで何かを取り出す」とかさ、そんなセマンティクスの上でクラス設計
してるのにさ、単に「キャストがいらないから」とか言う理由でソースに大なり
小なりとか書かれちゃさ、読みづらいだけだっての。

オブジェクト間のコラボレーションとかその存在理由を明確にしない（設計できない）
ヤツが、ジェネリクス構文でぐちゃぐちゃに書いたソースなんて読みたかねぇ。

OOも理解できない(勉強する気の無い)ヤツは C(か C++)に帰れ。

2GET's

関係無いけど、ジェネリックスのテンプレートって、キャストの解決
だけだっけ？

まともにクラス設計してコード書いてるヤツなら、そもそもジェネリクスが
あった所で、そんなにソースは変わらないと思われ。

http://homepage.mac.com/norika27/

>>1
いちいちスレを立てずに既存のスレをご利用ください。

【初心者】　Java質問・相談スレ25　【大歓迎】
http://pc2.2ch.net/test/read.cgi/tech/1054041744/
java死滅へのカウントダウン
http://pc2.2ch.net/test/read.cgi/tech/1044337040/
●●JAVAって死滅しちゃうの？？？？ PART6●●
http://pc2.2ch.net/test/read.cgi/tech/1047748598/

OOとジェネリクスは関係ない事をまず学べ

糞野郎は何使わせても糞コードを書く罠

>>7
関係無いけど、ジェネリクスの機能に重点をおいて「あぁここテンプレートで解決するのが前提だから」
とかっていうスタンスでクラス設計されると、モデルの立場があいまいにならないか？
って言いたい。
そしてそういうスタンスで書く気まんまんな開発者(C++出身者)がいて非常に困る。
..て話。

あ、
> モデルの立場があいまいにならないか

モデルって、なんらかのユースケースに含まれるオブジェクトの一つって、
意味ね。念のため。

そもそも「要件は決まっているが型が明確に決まらない」部分を作る時に使うものじゃないの？

うちではコレクションでのダウンキャスト避けにしか使わせない方向。

enum は便利そうだけどね〜

抽象概念から設計していくとすると、
逆に全部ジェネリック型な方が抽象っぽいような気がするけど・・・

>>11
それって、開発途中の話でしょ。まさか最後まで型が明確に決まらないの？
しかもこれってUMLベースの話じゃないよ。
納品物をコンパイルするためのソースでっていう話だよ？

>>14
開発途中ではある意味そうだと思うっていうか、そんな感じだろうけどさ。
開発終了までその状態ってどうよ。っていうか一度書いたらそのまま
行くでしょうよ。

しかもそのクラスを使う他のクラスも、全部それを意識する必要があるってさ。
それってどうよ。痛く無い？

なんの関係もないオブジェクトを汎用的な処理に突っ込めるね

コーディング規約レベルの話がIDEとかじゃなくて、コンパイラに含まれているっていうのは、
やっぱりSUN(とか)のマーケティングの賜物なんでしょうか。

なんかここで一発テコ入れしこうかい！とか言う。

>>17
ある意味多態。ていうか無法。リフレクション機構が死にまくり伝説。

汎用コンテナが安全に使えるのは単純にうれしい

でも汎用コンテナが安全でなくなるケースっていうのが想像し難い。

だって、テンプレートレベルで宣言できるって時点で、キャストだって安全に
書ける訳でしょ。

ここで分散オブジェクトの話持ち出して来たら、減点１。

減点されるの承知で。

分散オブジェクトでどうなるの？

JavaのGenericsが一体なんなのか分かってない奴が多数いる模様。

コンパイル時に型チェックするようにしただけですよ。
クラスファイルは変更なし。

>>23
「だってRMI経由でオブジェクトが来ると、何にキャストしていいかわかんなーい」
っていう旨の主張をしている人が過去に一人いたから。

HashMapだろうが、ObjectInputStreamからインスタンス再生だろうが、
送り手（あるいは保存主）が何で、何をそこに突っ込んだかがわかってる時点(そんなの
仕様で決めてから開発するに決まってんだろって意味)で、
キャストなんて解決してるハズだろうよって話の展開になったら、減点１って事。

だってRMI経由でオブジェクトが来ると、何にキャストしていいかわかんなーい

>>26
HashMapだろうが、ObjectInputStreamからインスタンス再生だろうが、
送り手（あるいは保存主）が何で、何をそこに突っ込んだかがわかってる時点(そんなの
仕様で決めてから開発するに決まってんだろって意味)で、
キャストなんて解決してるハズだろ

>>24
だから、そのマクロ臭いプリコンパイルに頼って、クラス設計を適当にするヤツが
いて困るって話では。

A「これがこの瞬間のDBへの更新の１トランザクションをモデル化したクラスで、
　こっちがその継承元のトランザクション管理のクラスで、あとこっちがDB処理の委譲関係クラス」

B「あ、そっすかじゃこのデータの山は全部HashMapにObjectでしまっておきます。
　だからテンプレートで全部HogeResultObjectって名前に固定して下さい。」

何か違うと思わないか。

>>26
二人目

>>26-27
再現フィルム（協力・劇団ひまわり）

>>25
> 「だってRMI経由でオブジェクトが来ると、何にキャストしていいかわかんなーい」
> っていう旨の主張をしている人が過去に一人いたから。
実際わかんないだろ。

>>28
それスゲー痛い。(笑

>>31
リフレクション(※１)を知らない様子。
ていうか、「実際わかんないし」ていう状態でRMIの受け手を開発しているっていうのは
いったいどういう案件なんだろうか。

※１・とりあえずjava.lang.Objectで受け取っておいて、Classを拾って、
　　　宣言を調べてClassLoaderから動的にロードしてみて見つからなかったら、
　　　仕様についてクレームをする。

>>28
専門用語ばかりで何言っているのか分からないよ(T_T)

漏れはあまりJava詳しくないからわからんのだけど、Genericsって、コレクション以外で
使う場所ってある？

>>34
[トランザクション管理クラス] ─(派生)→ [ある更新処理クラス(これをモデルとする)]
←(委譲)─[DB処理のローレベル担当]

... ここにブチ込むなんかのデータは、こいつらの都合がいいようなクラス(というかinterface)を
用意しておいて、それで明示的に送り込んだ方がわかりやすくないか、という意味。

「なんかの担当クラス」がその意味付けされた仕事をする為には他になんかのクラスが必要で
（コラボレーションの実現）それだからこそ、クラスの全体図が一つの地図のように見えたりするもの
なのにって事。
そこに宣言子と異なるオブジェクトが外部のルールでやってくるのが、気持ち悪い、と。

>>35
安直だけど、無いかも。そう考えるとますますいらないGenerics。

http://www-6.ibm.com/jp/developerworks/java/030613/j_j-djc04093.html
>>35
君が想像しているよりはいろいろ出来るんだよ。

話の流れとはジェンジェン関係無いけど、RMI（EJBでもいいや）で
キャストなんかいるのか？
Interface定義は（そこで使用されるValueObject定義も含めて）
サバ/クラ両方で予め交換しとくんじゃないの？

>>38
これって考察文献だよね。（内容読んだ？）

基本的には型総称(関係無いけどこの言い方が既にヤバい。総称するな、と個人的には思う）の話だよね。
その時点でコレクション（というかコンテナ）系の、「対象を特定しない"機能そのもの"の表現クラス」
との問題の関わりが出てくると思う。

そしてテンプレートという"機構"と、オブジェクト設計という抽象的なレイヤから降ろされた実物との
間に、なんか「変な溝」を感じる、と。

>>39
そういやそうだな。ていうかinterfaceの時点で "java.lang.Object" とか書かれてたら悪意を感じる罠。
スタブとか必要だしな。そういう意味でも事前にわかりまくり。

>>40
もしかして、オブジェクト指向とAspectJとかの間に溝を感じたりする性質？
「対象全てを横断して等しく機能を織り込む」なんて、気持ち悪い？

開発時の便宜の為の機能は「あるべき論」と切り離したほうがいいかと。

>>41
おそらくCORBAの話だったんだろうな。
CORBAのNARROWメソッドはアレだよな。

アレじゃわからん

>>42
要は、セマンティクスの間口をあるルールによって厳密で単純な構造に定義したJava言語の
構成が個人的にしっくりくる、と。ぶっちゃけちゃえばそういう事なんだけどね。
まるで細胞が集まって全体を作るようなイメージで。

そしてそこにある全ての「動き」すらも一つの「物体」という概念に収める事で、全ては独立し
関わりあっていると。

でも最近の流行はそこのレベルからのパラダイムシフトだったりするんだよね？
そしてそのシフトのトリガになっているのは、なんだかんだ言って現場の労力削減と、パズルの解き方の
ステップ省略にあると。

まぁ、正直オレが思うのはいつも理想論かも。

ま、それはそうと、安直な理由でテンプレート使いまくりなヤツがGenericsという武器を
手に入れると、正直設計が辛くなるのは事実。

>>46
バカは今まで公開インターフェイスでMap投げあったり(中に何はいってんだか
ぜんぶダイナミックにチェックしろってか？ﾏｼﾞｶﾖ！)するようなことを平気でし
てたから(被害者同盟会員1でごじゃる)、それよりはいくらかましな状態になると
予想しているが。

こんなクラスたまに見かける

class Foo {

　private HashMap map = new HashMap();

　public void add(String key , Bar bar) {
　　map.put(key,bar);
　}

　public Object get(String key) {
　　return map.get(key);　// ← ！
　}

}

あとこんなのも

class Foo {

　private ArrayList list = new ArrayList();

　public void add(Bar bar) {
　　list.add(bar);
　}

　public ArrayList getAll() {
　　return list;　// ← ！
　}

}

List#toArray()とか知らないのか ... 。

>>48-49
ご愁傷様

>>47
まぁね。でもテンプレートで解決されるのは、そのソース内だけだからね。
最終的に汎用的なクラスのインタフェースをそいつで解決する事を前提に作成してしまったら、
半年後に同じ汎用クラスを使う時、はたしてそこに詰まっているはずのオブジェクトの型を
覚えていられるだろうか。

>>48-49
あーあるあるって感じ。それ作った奴って、きっと値取り出す時の
相手の都合とか考えて無いよね。たとえIDEのコードアシスト使っても
戻り値の正確な型がわからないという最悪の罠。ウザい事この上無し。

それ解決させる為にテンプレート使うとか言う奴がいたら銃殺。

時代はもうGenericsを無視できないからな
「機能をカプセル化する」だけしか考えられないのは時代遅れだろ。

話の要点は「テンプレートで解決する事」に重点を置いてクラス設計されると、
再利用の際にもそれを知って置く必要があり、そしてその仕様が明確になっているならば、
なんでそれを扱うクラス群は、あらかじめそのクラスを元にやりとりしないのか？
って事。

従って"Generics＝悪"というより、テンプレートを安直に使われると困る、という話。

引用・１：
"そんなセマンティクスの上でクラス設計してるのにさ、単に「キャストがいらないから」とか言う理由で
ソースに大なり小なりとか書かれちゃさ"

引用・２：
"オブジェクト間のコラボレーションとかその存在理由を明確にしない（設計できない）
ヤツが、ジェネリクス構文でぐちゃぐちゃに書いたソースなんて読みたかねぇ"

あ、>>1 の引用ね。

型安全以上の思考ができないほうが問題。
Generics にはGenericsの設計があって、それをOOオンリーの設計の思考のまま理解しようとするから分らなくなる。
視点転換の必要があるのにそれができないから、汚く見える。
それは構造化プロクラミングしか知らない人間がOOプロクラミングをみると汚く見えるのと同じ。
まあ、まだGenerics は十分に研究されていないという問題もあるがね。

>>57
十分に研究されていない問題をはらんだGenericsを、ただのタイプセーフ問題
の解決にしか使う気の無いJavaの経験が浅い開発者と一緒に仕事する事になってみ。
>>1 のグチもわかる。

Genericsでソースが汚れるんじゃなくて、ソース汚すヤツこそが単純に害。

テンプレートブラックマジックが誰にでも分り、誰にでも使えるような定石ができてきたら状況は一変してくるだろうね。
実装言語が増えてきて、実践で使う人が沢山でてくれば机上の空論がちゃんとした理論になるんだろうけど、すぐという訳には行かないかもね。

型総称性はかなり研究されているし、
強く型付けされた関数型言語(MLやHaskell)なんかでは
相当前から取り入れられていますが
その辺は無視ですか？>>57

.NETなんかはF#(OCaml)でgenericsサポートしてるわけだし。

とりあえず、>>1 の悩みには同意するのかしないのか。

>>1
えー　俺はキャストが沢山あるほうが見にくいソースだと思うぞー

これがわかってればOOわかってるみたいな基準ってありますか？

とりあえず、考えるべきは
今のJAVAにGenericsを取り込むと何がいいのか？
でしょ。
メリットがあるなら、
デメリットが何であるかを理解しながら
使えば問題はない。

俺はよくわかっていないので、
識者の方型教えてください。

Genericsってのは
http://objectclub.esm.co.jp/JavaGenerics/
この程度だと理解していいのかな？

>java.util.Collection系クラスの問題点
>
>要素取り出す際にはキャストが必要．
>意図しない型の要素も追加できてしまう．
http://objectclub.esm.co.jp/JavaGenerics/
からの引用だけど

この２つの問題点を解決するためだけに使うのであれば、
俺は問題ないと思う。
むしろ、歓迎だと思う。

>>65
ポリモーフィズムとデザパタがわかってれば、
あとは経験だろ

>>13
enumいらね。

public interface EnumTable {
　public Object valueA = new Object();
　public Object valueB = new Object();
　public Object valueC = new Object();
　public Object valueD = new Object();
}

>>69
TypesafeEnumの自力実装って問題あるんだよ。知ってる？

>>70
どんな問題ですか？
教えてください。

>>71
Enumというからには、equals()じゃなくて==で同値比較することが出
来てほしいもんだと思っている人が多いはずだが、分散オブジェクト
環境では、往々にして同じ値を示すべきものが別インスタンスになって
しまって、==の比較がfalseを返してしまうことがある、ということ。

演算子のオーバーロードをすればいいじゃない

>>72
readResolveメソッドを適切に定義すればよいだけのこと。

「ClassLoaderが異なる場合は…」なんてゴネる香具師もいるが、
そもそもClassLoaderが異なれば全く別の名前空間。
そんなことが気になる設計をする方がマズイ。

>>73,74
現状でも代替手段があるからいらないという意見もわかるが
言語側で面倒を受け持ってくれるならその方が便利でいいじゃん？

使う場面なんかねーだろEnum

クラスの継承とかファクトリとかインタフェースとか。

Enum欲しいいってるやつは設計が糞

>>76
本気で言ってますか？

>>69
それは、たとえばEJBとかでは使えんなぁ。
さて、何故でしょう？わかった人は初心者卒業。

>>76
クソなのはお前の脳味噌だろ？

>>75
> 現状でも代替手段があるからいらないという意見もわかるが
> 言語側で面倒を受け持ってくれるならその方が便利でいいじゃん？

確かにな。
>>69のような不完全なEnumを実装する香具師がいなくなるって
メリットはある。

けど、俺の中でのJava言語仕様に取り込んでほしいランキングは
Generics >> Enum >>>>>>>>>>>>>>>>>>>> 演算子の多重定義
って感じかな。
「あると便利かも知れんが、なくても構わん。」
ってレベル。

Javaのgenericsなんて糞。.NETみたいに関数型言語でエレガントに実装しろよ馬鹿。

リフレクション上 List<String> と List<Integer> に何の関連もないなんて何て糞な実装だ。(ﾜﾗ

だってJavaだもん

>>73
> 演算子のオーバーロードをすればいいじゃない
そういう汚染系機能はいらんな。equals()メソッドをオーバライド
する規約にしたほうが開発者同士の混乱を最小限に抑えることができる。

>>81
そもそもC#にはGenericsなんてないもん。
よってC#はもっと糞

>>85
あるよ。

>>86
Yukonとかいったらぶっ殺す

Javaって演算子オーバーロードないのに、どうして
Stringにだけは＋が使えるの？

文字列は基本型に近いから String も特別扱いされてる。
(他の言語では文字列型が int や double と同列に扱われているものもある)

+ もそうだが "" で囲むだけでインスタンスになるのも
クラスとして見たらかなり特別扱いされてるところだね。

>>88
ぶっちゃけ、設計者の独断。

>>89
近いだけなの？基本型じゃないの？

>>88
+　は print()文使用時に役に立つ。が、StringBuffer#append()より遅い。
もしC#のように == まで勝手にString()#equals()と同等な振る舞いを持つように
オーバーロードされては不便。文字列は同じだがオブジェクトは異なるといったことができなくなる。


>>91
基本型ではなくクラス。

JavaのString型はかなり特殊。
あらゆるプリミティブ型やオブジェクトをString型に代入すると
暗黙のうちのそのオブジェクトからtoString()メソッド(primitiveの場合はラップクラスのtoString())が呼び出される。
ある自作クラスのデフォルトのtoString()が気に入らなかったらtoString()メソッドをオーバライドなどすればいい。

>>92
> 文字列は同じだがオブジェクトは異なるといったことができなくなる。

JavaのStringでそんなことできるの？

>>93

出来ます。

Java言語規定 第2版
http://www.y-adagio.com/public/standards/tr_javalang2/jTOC.doc.html

3.10.5 文字列リテラル
http://www.y-adagio.com/public/standards/tr_javalang2/lexical.doc.html#101083

をご覧ください。

>>92
>> +　は print()文使用時に役に立つ。が、StringBuffer#append()より遅い。

なんか誤解を生みそうな書き方なので勝手に補足。

+はコンパイル後StringBufferに変換されるため、速度は変わらない。
ただfor文の中で+を使用して文字列を連結されるような場合だと、
そのたびにStringBufferをnewすることになるので、パフォーマンスが悪くなる。

>>95
StringBuffer str = new StringBuffer();
str.append("A");
str.append("B");
str.append("C");

よりは
"A" + "B" + "C";
の方が、

StringBuffer str = new StringBuffer("A");
str.append("B");
str.append("C");

になるから速い。（嘘

>>96
ネタついでに、"A"+"B"+"C"は、コンパイル時に
"ABC"に置換されるから、物凄い速いよ。

>>97
それは言語仕様ですか？それともSunのコンパイラが
そう評価するという話ですか？

http://www.y-adagio.com/public/standards/tr_javalang/15.doc.htm#39990
>>98
仕様ではないようですな。
んでもって、Sunのコンパイラはそうしてますな。

>>98 さんは、「仕様と実装を区別しようとする姿勢」を持つことができてますな。
アタリマエのことだけど、そうでない人の多いこと・・・。

>>100
変数は使いまわしたほうが速いよ！ホントだよ！

で、Genericsは必要ってことでいいよね。　キャスト無い方が見やすいし。

Genericsのメリット
キャストが減ってｳﾏｰ

Genericsのデメリット
馬鹿が馬鹿なコードを書くのを助長する

Genericsのデメリットへの反論
ばかはどんな言語仕様であろうと、どうせろくなコード書かない

イヤーンなのは、ソースが綺麗だの汚いだのいっている奴に限って、やたらアクの強いめちゃくちゃ汚いソースを書くって所かね。
たとえは 1 見たいな事を言うような奴とかね。
設計設計言っている奴にろくな設計をする奴がいないんだよな。

C#がGenerics実装すんの待ってこけるかどうか見極めてから実装すりゃいいじゃん。
正直JavaやC#でGenericsを使っても、キャストが減って便利、以上の収穫は得られないと思う。

>>105
その収穫で十分じゃん。Generics欲しい。

>>105
.NETのGenericsはこけようがない。
元々は関数型言語のPolymorphismをC#でも利用できるようにしただけだから。

その点、単一言語主義のJavaの方はこけてしまったら何も残らない。

単なるコンパイル時点でのプリコンパイルもどきで、バイナリ互換は
保たれるなら、便利なシンタックスシュガーだと思えばいいだけちゃうの？
こけるってなにがどうこけるんですか？

よく仕組みをしらないけど、コレクラスファイルのサイズ増えたりしないの？

>>109
コンパイル時に型チェックするという作業が、コンパイラに増える
だけらしい。

>>107
こけるといっても言語はOSと違うもんだ。C#や.NETはJavaほどにWindowsに依
存しやすいようにはなっていない。多くのOSに対応しOSに対する依存性が少ない分
こけても生き残る。

日本語変だな

>>111
こっちは素面だが、なに言ってるかわからん。

【猿が】Java厨ﾆﾊCommunicationSkillｶﾞ必要【ﾃﾞｽﾏｰﾁ踊る】

>>111の翻訳に挑戦しました

C#や.NETはJavaよりもWindowsに依存しにくい
OSに対する依存性が少ない言語はこけても生き残る
よって、C#や.NETは生き残る

あれ？

言語仕様をシンプルに保つっていうのはJavaのいいところだと思ってたけど違うの？
Generics云々よりも、関心のあるところはこういう技術"外"の話なんだけど。

>>116
同意
こうやってどんどん仕様が肥大化していっていつかC++の二の舞になりかねないぞ

Genericsごときでこれほど大騒ぎしているうちは大丈夫

Java は冗長なところが貫かれていて一貫性あったけど、
こんな具合にやられるとなー。中途半端だ。

言語仕様の変更にはネガティブである必要あると思うよ。

中途半端だし、やっぱ無駄。

つーか無くていい。
コレクションがなんでも入って困るというなら、それを利用する側（イメージとしては、あるクラスが内部に値を保持する為に
privateにコンポジットしたコンテナだとか思いねェ）が、ゲッタ／セッタで制御すればいいっつーか、
そういう風に普通しねぇか？

class Data {
　private String arg = null;
　public String get() {
　　return arg;
　}
　public void set(String arg) {
　　this.arg = arg;
　}
}

// このクラスはライブラリとして利用されるものとする。
class DataList {
　// listには Data型しか格納されない。
　private ArrayList list = new ArrayList();
　public Data get() {
　　return (Data)list.get();
　}
　public void add(Data data) {
　　list.add(data);
　}
}

これって普通だよな。

> public Data get() {
> 　　return (Data)list.get();
>　}
コンパイルエラー

>>122
いちいちそう書かなくていいようにあるんだろ

get と add程度 しかメソッドが必要ないならそれでもいいかもしれないが
ホントにリストとして使いたいときに
List インタフェースの豊富な便利なメソッドが使えないのはイタイ。

>>122
そういうのを自動生成してくれるツールないの？

>>125
メソッド一つあたり3行追加すれば良いだけだし。
(Iterator返すメソッドとかを除いて)

>>126
どうせ自動生成に頼るのだったら
Generics導入してもいいと思うが。

結論。

>>122のようなコードを自動で生成してくれるGenericsは便利である。
特にメソッドが増えるたびに3行増えるので、
メソッドが多いほどGenericsは便利になる。

>>128
いや、Genericsが使えない(サポートする予定が当面ない)コンパイラでも使えるので便利かなぁと思ったんですが

>>129

ヴァカっぽいなー、そんな意味の無いクラス作ってどうすんだ。
クラスローディングのコストも結構あるだろう。

コードの自動生成（Relaxer や DBソフトが自動生成するコードとか）ってのは
良心的でないと思う。自動生成するなら xml とシンプルな Factory クラスだけに
していただきたい。

--

漏れが思うのは、Java は冗長である意味バカ向けの言語だけど、
大抵の組織は一人一人は頭良くても人数集まるとバカになるから（例外あるけど）
このままシンプルなバカ向けの言語仕様を貫いていただきたい。Generics は不要。

>>131
組織の能力はメンバの能力の最大公約に制限されるからな

package 2ch.tech;
public class Aori extends Res {
pulic static void main(String [] args) {
System.out.println(">>131 馬鹿とか言うなー。");
}
}

つーか、>>122 のソースは（一部アフォなバグがあるが）別にあのまま使うというより、
何かの断片だと思いねぇ。
なんかの要件で設計されたあるクラスの一部について、「あんな感じのゲッタ／セッタ」を含んだクラス
ってのは、普通に書くだろ。そしてその時コレクション系やリスト系はたいてい裸のまま外に出さないで、
それを包含するクラスの方が外に出るだろ、要はそれを言いたい。

>>131
> Java は冗長である意味バカ向けの言語だけど
それでいい。ていうか、言語仕様が冗長だとバカ向けか？オレの中ではコーディングレベルの冗長性なんて別に
どうでもいい。
「全体の中でどんなクラスを書き、配置するべきか」を考える事に集中できるなら、
もっとバカ仕様でもいい。（本当か）

自己レス・補足
> コレクション系やリスト系はたいてい裸のまま外に出さないで、
> それを包含するクラスの方が外に出る

念のため。例えばコレって言うのはつまりこういう事。

1) クラスＡは（例えば値は最終的にはただのStringだとしても）DBからの検索結果を保持する物である
2) クラスＢはその結果を表型にまとめるものである。
3) クラスＣはその表をなんらかの形（たとえばXML等）にトランスフォームする

とあった時、クラスＣはその仕事をまっとうする際、クラスＢから例えばList形式で値(クラスＡインスタンス)を
一つずつ取るか、あるいは、クラスＢに表の位置を指定して値（クラスＡインスタンス）を取るかするでしょう。
その辺のインスタンス間のコラボの際、例えばクラスＢとかが内包してそうな List系オブジェクトを外にそのまま
出すか？という話。
ただ、これが「Listを実装したこの意味で独自な」List系クラスを作ってあって、それが返るというなら、
たぶんＯＫ。

言語仕様なんて単純な方がいい。凝るのは中身だ。

Genericsはより「全体の中でどんなクラスを書き、配置するべきか」を考えるために無駄を省いてくれると思う。

122のDataListみたいなのは本来は立派なクラスとして設計の一部になるべきだけど、実際は単なるラッパクラスとして型安全＆キャスト省略のためにしか使われて無いのも事実。
だったらそんなのははじめから自動でやらせてほかの事に力を入れるべきだと思う。
ただしGenericsを使った場合、本当にただのラッパに成り下がって、特別な機能をもたせたくても出来なくなるよね？

今うちの会社ではまだ開発の中でGenericsの話って具体的に出てきて無いけど、
他のメンバの中に危険な発言をする者がいる。

#１個のクラス中に丸々処理をごっそり書いて、それが汎用化されそうになったら、
#テンプレートでタイプを限定させよ！とか..。

...なんか、将来の顛末を >>1 に予言されているような気がする ...。

>>137
すまん。例が悪かった。あれは、単なるラッパの例として出したかった訳じゃない。
( >>134 参照)

>>138
そいつマジで言ってたら猿以下だ・・・

>>140
しかも「そんな事するんだったら、もともと汎用化される事をある程度想定して、クラスやらインタフェースを分けて設計しとこうよ」
って言ったら、
「これでいいじゃん！なんでそうしなきゃいけないの！？」と逆ギレっぽい反応された....。

さらに、「もし他の開発者がそのクラスを使う時、そのテンプレートによる修飾のルールを知らなかったらどうする？
IDEのコードアシスト使っても推奨される型なんて判別できないよ。」って言ったら、彼は

「忘れなければいい」という名言を吐いてくれました。

何故 型やインタフェースで処理の連携を書くのをイヤがるんでしょう。わからん(笑

DataList 作るよりは、Data[] を返すメソッドを定義してそれを活用するようにしたほうがいい。

>>134

頭よければRubyとかタイプ量少なくて済む言語を使うよ。

ここでいう「ばか」とは、組織に合わせてスマートさを少し捨てるという意味だ。

もともとget, setメソッドを書くなんてバカバカしいでしょ。
増してそれに Javadoc を書くなんざ。（漏れらはアクセサのJavadocは特別な場合は除いて書かなくてＯＫってことにしてる）

しかしそれでも、たまにはそれが役に立つことがある。
デバッグがしやすいにもある意味、ばかだからなのだ。

タイプ量減らしたいだけなら、Cかなんかのプリコンパイラでも使え。
Velocityとかのテンプレートエンジンでもいいぞ。

えーと、プロパティが欲しいってこと？

publicフィールドを書いたらエラーになって、
get、setを自動で作ってくれる、
プロパティと同じ働きをするものを
冗長なコードとして出力してくれる機能がほしい。

>>146
IDE使えばたいていついてるだろ。

IDE使うとプロジェクト依存になりそうで嫌なんですよ。

正直、その程度の機能ならちょろっと自作できるだろ

Javaにもプロパティがあったらよかったのにな。
どうせ、プライベートメンバなんて
setter、getter経由でしかアクセスしないのだから。

とおもった人がC#の開発陣にいたよというお話でした

>>150
確かに、obj.propと言う風に使うとして、
propがパブリックメンバにも、
プライベートメンバにも変更可能なのは
利点だと思う。

Javaだと、obj.propをgetter、setter経由にすると、
obj.getProp、obj.setPropに名前が変更されるからね。

Rubyおもいっきしset/getでしょ。

> プライベートメンバにも変更可能なのは
なんかおかしかったな。修正↓

propを名前を変えることなくgetter、setter相当(プロパティ)に
変更可能なのは

俺は名前空間が無い言語でXXX_とかいうプリフィックスをつけて区別していた。
名前で意味を変えるという手段はもうやめてほしい。

>>150,152

public void setProp(Prop prop) { this.prop = prop; }
public Prop getProp() { return prop; }
というsetter, getter ならプロパティで obj.prop = prop, obj.prop とするのもいいだろう。
しかし例えば内部でセットする値の妥当性チェックもやってる setter の場合
obj.prop = prop と書くのはなんか気持ち悪い気がする。

というかあなたらカプセル化の利点・欠点についてわかってないでしょ？

>>156
あんたプロパティの意味わかって言ってる？

>>156
その利点・欠点をあなたがまず語ってください
話はそれからだ

>>156
間違っているよ。修正しといてあげる。

> しかし例えば内部でセットする値の妥当性チェックもやってる setter の場合
プロパティでやれるから便利である。

プロパティが無くてもタイプ量は5文字程度しか変わらないんだけどね。
その差もIDEとかの入力支援があれば殆ど気にならんし。

Java厨の認識・知識はその程度のもん。
語るに落ちる

>>160
正確には使用している個所×5文字ですね。

Genericsが無くてもちょっとタイプ量が増えるだけ。
そういうことを繰り返すからタイプ量が膨大に増えるわけですね。

カッコが面倒

#が出てきたときにお偉いさんが、プロパティはその内部のコストを見落としてしまうので著しいパフォーマンスの低下につながるっつって非難してなかったか。

タイプ量増えるって言ってる人々ってIDEの入力支援使ってないの？

プロパティの場合
単純なgetter setterではない時に、可読性が落ちる位だけど。

まぁダメな奴はどんな言語仕様にしてもダメコードを書くということですよ

スレ違いかもしれんが
プロパティあるとgetterメソッドにしようか、読取専用プロパティにしようか迷うね

ごめんにょ、Javaに戻る気がしない。

obj.info.name = "hoge"
　　　↑実はinfoのクローンが返っているので、この代入は無効

こんなバグが大量発生の予感

>>170
それは
obj.getInfo().setName("hoge");
と書く場合でも起こりえることだと思うが。

>>171
起こりえるけど警戒度が違うと思u

>>165
誰だよ、そんなことあるわけないだろ。

>>166
タイプ量はツールでカバーできるが、見通しが悪くなるのもあまりよろしくない。
漏れは、Java は許容範囲で、これはこれで一貫性があってイイと思う。

>>168
？

プロパティがあるならプロパティにすればいいだろ。
むしろプロパティがないとパブリックメンバにするか、
getterメソッドにするかで悩むと思うが。

>>170
なにが無効なんだ？ 作り方が悪いだけだろ。

Eiffelの、公開データメンバでも外からの代入は不可、はいい妥協点だと思ったり。

>>173
.NETのColor構造体のR・G・Bの各プロパティは恐ろしく遅いよ。
だけどプロパティだとついついループの中とかで使ってしまうから全体の処理速度にかなり響いてくる。
プロファイルしてみるまでまさかそこがネックになってるとは思いもしなかった。

・・・俺がへたれなだけだが

>>161
>Java厨の認識・知識はその程度のもん。
>語るに落ちる

お前は何だかんだいってJavaが好きなんだろ。
わざわざこんなスレにまで遠征するとはよほどC#の将来に危機感を感じている証拠だな。
賢い奴ならJavaに将来性を感じないならわざわざこんなスレにレスをする馬鹿なことはしない。
それでもJavaを貶してJavaプログラマの人格批判するようなレスする馬鹿はお前くらいだ。

Javaを貶し煽り議論の邪魔をするような奴だろうとJavaスレにしつこく
厚かましいレスをするのが好きな奴は皆Java厨。
つまりお前もJava厨だ。

>>166
> タイプ量増えるって言ってる人々ってIDEの入力支援使ってないの？
IDE中毒だな。UMLモデリングツールを使うってならわかるが
UMLモデリングもしょぼいVS.NETチック、VBチックなIDEは好かん。
M$のIDEはこれから流行るプログラミングツールの原型にはなりえんな。

これから流行るプログラミングツールの原型としてはRationalがふさわしい。

C#ではset/getが使えただけで果たしてJavaより本当に使いやすくなったのか
という議論はどこかのスレでもすでに散々議論されていたと思うのだが。

set/getがあるから便利とはいえ、ワープロ専用機は昔のPCのようにインストール作業
をしなくて済むから便利といっているようなものでしかない。拡張性を下げているってこった。
所詮set/getしか使えないお粗末な機能だ。

C#のset/getの欠点は
メソッド名でsetで代入できる値の定義域を見分けることができない。
プロパティなのかインスタンス変数のpublicなフィールドなのか一目で区別しにくい。
(Javaではオブジェクトがsetterメソッド、getterメソッドを使っているところを見ればすぐにわかる)

この程度のことでJavaとC#どちらを選ぶかという議論は、
拡張性の高いPCを買うか、それとも拡張性はないが便利な電卓を買うか、
といっているようなものだ。

まあC#はこれからも好きなだけ色んな便利機能追加して、結局cに似たVBになるんでしょうから

>>179
長々と書いてくれたんだが、喩えが的を射ていないのが残念だ。

> プロパティなのかインスタンス変数のpublicなフィールドなのか一目で区別しにくい。
厳密にはpublicフィールドは存在しません。
すべてプロパティ扱いです。
publicフィールドはなし。すべてsetter、getterでアクセスしろよりましでしょ。

>>180
そういうJavaもあれほど不要だと言ってきた機能が追加されつつあるけどな。

enum はずっと欲しいと思ってたよ。

>>183
だれが何を不要といったものかね？
ゴスリングが不要といったものが追加されたとでも？
あれは「C#にもあったものは不要といわれていたものが追加された」
のではなく「C#にあったものとは似て非なるものが追加された」というのじゃよ。

いつのまにかプロパティの話に

>>185
言葉遊び。恥ずかしい。

>>179
メタデータとしてメソッド／フィールド／プロパティが明確に区別できることが一番重要なんだけどね。
見た目の区別しか考えてないのがJava厨の浅はかさと言うか。

>>188
あんな馬鹿といっしょにしないでくれ…

>>188
メタデータとしてメソッド／フィールド／プロパティを区別することが
なぜ重要なんですか？

>>190
処理の意味が明確になる

>>188
うーんそうか？現実問題、区別しないでつかってるんだけど…
getterとsetter(に見えるメソッド)があっても、それが具体的な「一つのフィールド」
を書き換えるという処理をしていない、っていうクラスを書くケースはいくらでもある
んだけどな…俺が変なのかな？

>>191
・メソッドとプロパティを区別する意味
・フィールドとプロパティを区別する意味
についてもう少し詳しく教えてください

>>193
・プロパティは呼ぶ順番を気にしなくて良い（気にしなくていいように実装するべきである）
　control.Offset = new Point( 20, 30 );
　control.Parent = parent; // ←↑順番を変えても同じく動作しなければならない。
・プロパティは、オブジェクトの状態を変更する以外の副作用を起こすべきではない。
・上記理由と、さらにオーバーロードされることがないのでRAD開発にも有利。

・プロパティは内部で何をしていても使う側からは見えないのでバージョン間の互換性が取りやすい。
　フィールドに、途中で範囲チェックを加えたくてプロパティにすると、そのコンポーネントを使用している全てのプログラムのリビルドが必要になるが、
　いったんプロパティにしてしまえば中のコードをいくら変えてもその必要はない。
・プロパティは実際のデータと1対1に対応しているとは限らない。
　2つのフィールドに対応するプロパティや、フィールドとは無関係なプロパティも存在してかまわない。
　プロパティは概念的に属性というものを表現するときに使い、それが実際のデータに対応いている必要は無い。
　これもバージョン間の互換性を高める。
・プロパティは（実装的にはメソッドの仲間なので）継承・オーバーライドできるしインターフェイスにも含めることが出来る。

こんなところかな。

>>194
区別する意味が一つも書いてないよ。

プロパティだけの話じゃないし。対比させて書いてよ。
プロパティは〜で、フィールドは〜で、メソッドは〜と言う風に。

> フィールドに、途中で範囲チェックを加えたくてプロパティにすると、そのコンポーネントを使用している全てのプログラムのリビルドが必要になるが、
ならない。むしろ、フィールドに 〜略〜 setterにすると 〜略〜 リビルドが必要になる。

>>188
一口にメタデータといっても無数にあり、君の思っているようなメタデータは
どのプログラマも想像するようなメタデータとは異なるわけだ。

君のように、メタデータといったらこれしかないと勝手に思い込み
自分にとっての重要性(価値観)を関係ない者にまで押し付けるかのような思考が
VB厨とC#厨とマイクロソフト信者厨の浅はかさというか。

フィールドとの対比はかいてあるじゃん
ある言語に依存した事もかいてあって偏ってるけど

>>194
そのC#独自仕様のプロパティを使った場合のデザインパターンやアーキテクチャパターンの
サンプルソースを見せれ。

>>188
> >>179
> メタデータとしてメソッド／フィールド／プロパティが明確に区別できることが一番重要なんだけどね。
> 見た目の区別しか考えてないのがJava厨の浅はかさと言うか。

ていうかお前邪魔だからこスレに二度とレスしなくていいよ。
暴れるならJava死滅スレで暴れてくれ。

>>194
それを見ているとプロパティのオーバーライドはプロパティでしか使えないようにしか見えない。

>>195
スマンなわざわざ対比しなくても明確になってると思ったが。
・プロパティは呼ぶ順番を気にしなくて良い（気にしなくていいように実装するべきである）
　→メソッドは順番に依存してもかまわない（そのようなガイドラインは無い）
　　たとえば正規表現でFindする前には必ずCompileしなければならない、など。
・プロパティは、オブジェクトの状態を変更する以外の副作用を起こすべきではない。
　→メソッドは別にいくら副作用を起こそうが関係ない。
・上記理由と、さらにオーバーロードされることがないのでRAD開発にも有利。
　→メソッドはオーバーロードされ開発環境がどのメソッドを呼ぶべきか適切に判断するのが難しい、
　　フィールドに値をセットするメソッドが1つの引数だけを持つとは限らない。

・プロパティは内部で何をしていても使う側からは見えないのでバージョン間の互換性が取りやすい。
　→フィールドはさっき書いたとおり。
・プロパティは概念的に属性というものを表現する。
　→フィールドは実際のデータを表現する。複数のデータで一つのフィールドとかは出来ない。
　　そのフィールドを含むオブジェクトが、値が変更されたタイミングを知る手段は無い。
・プロパティは（実装的にはメソッドの仲間なので）継承・オーバーライドできるしインターフェイスにも含めることが出来る。
　→フィールドはインターフェイスに含められない、オーバーライドできない。


ところで、フィールドをプロパティにしても本当にビルド必要ないのか？
.NETは必要だったはずだが。

http://homepage.mac.com/yuuka20/

>>194
> 　プロパティは概念的に属性というものを表現するときに使い、それが実際のデータに対応いている必要は無い。
> 　これもバージョン間の互換性を高める。

お前言ってることが何かおかしくないか？

属性といったらフィールドのことだろ。
UMLではフィールドのことを「属性」と表現している。

>>201
Javaとは関係ない話題はC#スレに誘導してやれ。

>>203
UMLではでしょ。
property:財産、資産、特性、属性

>>203
俺はJava屋でMSの概念はよくわからんが、どうやら昔からフィールド
とよんでいるものを、2つ以上の役割に分割したいらしいね。

オブジェクトの内装なんか、実装した奴の勝手のようなきがするのだが。
プロパティセットと実オブジェクトをコンポジションすればいいだけの
ように聞こえるなあ。

「C#のプロパティ」って動脈(メソッド)と静脈(フィールド)が混ざり合った両生類の
心臓のようなキモイものみたいだな。

C#厨が珍しくメンバ関数のことをメソッド、メンバ変数のことをフィールドと言ってる。

>>205
> >>203
> UMLではでしょ。
> property:財産、資産、特性、属性

オブジェクト指向といえばJavaといわれる中、独りよがりはいけないよ。
OMGの基準に従っとけよ。

俺は必死な>>201のC#のプロパティの説明が、
「C言語にはポインタ、関数ポインタが使えJavaよりも柔軟性が高いので
JavaよりC言語の方が便利ですよ」
といっているようにしか聞こえないのだが。

外からみればフィールドの「実装方法」なんかどうでも良い

>>209
んじゃ属性->特性
別にどっちでもいいよ。そんな和訳は重要じゃない。
多分に書き方が悪かったが
・プロパティは概念的に”属性”というものを表現する。
ではなくて
・プロパティは”概念的に”属性というものを表現する。
なんだ、強調したいのはこっち。
実際のデータを扱うフィールドとは違うよって事。

>>207
そこをキモイとみるかどうかは人それぞれだろうな。
フィールドでは役不足だがメソッドでは冗長って事もあるからそういう集まりに対してどちらでもないプロパティというものを持ち出しても俺は別に悪くは無いと思うけど。

両陣営で言葉の定義が違うのになにやってんだおまえらは

>>201
> ・プロパティは内部で何をしていても使う側からは見えないのでバージョン間の互換性が取りやすい。
> 　→フィールドはさっき書いたとおり。

これを見ると初心者馬鹿には「JavaよりC#のほうがすぐれているじゃん」と
錯覚しそうだがカプセル化を理解している者ならそんな誤解もあるはずが無く。

C#厨のC#言語普及のためのプロパガンダ戦術(宣伝工作)にも見えるのだが。

>>213
少なくともM$の言葉の定義やネーミングセンスは技術者の視点からみると
独善的で政治的で最悪。

「Activeなんたら」「なんたら.NET」のようになにもかもM$の定義に従い、
M$に洗脳されるのはばかばかしい。

単にOOPの一般的な仕様に対する、特定用途用のサブセットでしかない
存在を自慢げに語っている馬鹿がいる、という理解でいいのかな？
Javaなら、JavaBeansをコンポジットしたクラス作れば終わりだな。

193の疑問に答えただけでプロパガンダとか自慢げとか叩かれる俺ってかなり悲惨だな。
そもそもJavaと.NETの比較なんか論点の端っこにも存在しないだろ。
Javaにプロパティを入れるのが是か非かって話のはずだ。
今のところJavaにはプロパティが無いみたいだし、説明するにはC#のを使うのが一番だろうと思ったが。
なんか言葉の定義すら違うみたいだから俺はもうダメぽ。
だれかJava風にメソッドとプロパティとフィールドの違い教えてやってくれ。

>>212
> そこをキモイとみるかどうかは人それぞれだろうな。
> フィールドでは役不足だがメソッドでは冗長って事もあるからそういう集まりに対してどちらでもないプロパティというものを持ち出しても俺は別に悪くは無いと思うけど。

そんなことで大規模プログラミングで生産性があがるのか疑問。
特定の用途にのみ生産性があがり、いざというときに、「これをしたい」というときに
発生する副作用が気になるところ。

果たして、デザインパターンでも役に立つんだか
継承関係にあるメソッドにわざわざそんなものをつける付加価値は、
デザインパターンの適用に比べたら、ちっぽけなものでしかないのではないかと。

>>217
>193の疑問に答えただけでプロパガンダとか自慢げとか叩かれる俺ってかなり悲惨だな。
>そもそもJavaと.NETの比較なんか論点の端っこにも存在しないだろ。
「Java厨は〜」と煽るからいけなんだろ、と思う。

しかしJavaプログラマは言語仕様に関しては保守的な意見が多いな
使わなければいいだけの話なのに

>>220
勝手に使う馬鹿がいて、それを修正、解読、
リバースエンジニアリングしなければならなくなる負担が嫌なのだよ。
C#でunsafeなんか使ってちゃソースコードの信頼性を確認するときの負担も
Javaよ比べるとばかにならんと。


それとよ、言語仕様からしてC#はJavaよりバグの原因をつかみにくい言語だと思うがどうよ。

>>218
まぁ大規模プログラミングについては俺が語れることじゃないが。
昔classからinterfaceを取り出したのと同じようなことだと思うな。
C++erに言わせればそんなもん抽象クラスでまかなえるんだから必要ないって話になるが、
それでもinterfaceは十分にその意義を確立した。
今でもC++にinterfaceは無いが、無くても全然困らない、多重継承とかもっと強力な言語サポートがあるから。
Javaでもプロパティが無くても困らないよ、メソッドがあればプロパティで出来ることは全部できるんだから。
プロパティはあくまで概念を明確にするためのものでしかない、
あればあるで使うだけ、無くても代替手段はある。

>>219
俺は一度も煽ってないよ。別人。

なんでC#とJavaの話になってるんだよ。
Genericsはどうでもいいのか？

昔ボーランドが Javaにプロパティを入れてくれと頼んだがやっぱり断わられたそうだ。
同じような理由からだったと思う。beansにもシリアライズで対応出来るからとか、

でも、結局、入れておけばJavabeansも今のC#コンポーネント的に出来ただろうにと残念な感じはある。

その頃、Delphi for java とかのアナウンスもあったから、JVMがDelphiに乗っ取られるのが嫌だったのかなあ

メタデータで区別できる → リフレクションで区別できる だろ。
Javaでどうやるんだよ？

メソッドの頭に「get、set」がついてたらプロパティだなんて糞アホな仕様だと思わない？
メソッドの頭に「test」がついてたらunit test用メソッドだなんてみっともないと思わない？
クラス名に「<〜>」が入ってたらgenericsクラスだなんて嘲笑激藁な仕様だと思わない？

.NETはリフレクションですべて綺麗に区別出来るんだよ。
そのメリットが分からない奴はセンスがないからプログラマやめた方がいいぞ。

ネーミングルールを利用して運用でカバーするのが
Javaのやり方です。プリフィックスって知らない？

アホアンチがﾃﾞﾙﾊﾟｲのプロパティまで否定したのか。(ｹﾞﾗ

スーパー
　スーパー
スーパー
　　　スーパー
スーパーハンガリアーン


　　　スーパーハンガリアーン

メソッドのシグネチャを見れば分かるならいいじゃん。
Java が出来たのは 1995 年だということをお忘れなく。

JSTLのelを知ったとき、「やっぱJavaにもプロパティあった方がいいのか」と
思ったのは俺だけですか？
elでは、$hoo.bar と書くとfoo.getBar()と同じ意味になる。
値をセットする文脈で使えばfoo.setBar(buz)になる。

そういやGenericの話はどうなった？

>>228
ハンガリアンがいただけないのは、
オブジェクトの役割ではなく型に基づいて命名している点と、
守らなくても動作するのでしばしば規則を破られる点。

Javaのgenerics仕様は糞。
将来.NETの仕様をパクる羽目になるよ。

>>230
Generic は Java に導入されるので、
C++ や Effiel や C# のそれとの違いを調べてない人は、
プロパティのように 「プロパティもないのか」 と単純な煽りができない。
よって話題にできる人が限られている。

>>228
Javaのプロパティがいただけないのは、
メソッドの役割ではなく名前の形に基づいて命名している点と、
守らなくても動作するのでしばしば規則を破られる点。

ありゃ。
s/Effiel/Eiffel/

>>233
Javaのgenericsは、それがgenericsから作られたことをクラス名でしか判断できない。
リフレクションでは判別できない糞仕様。

>>236
つまりはset〜、get〜のプロパティと同じ。

>>234
> メソッドの役割ではなく名前の形に基づいて命名している点と、
わからん。
ってゆーと理解できない奴がバカとか言われんだろうなぁ。

> 守らなくても動作するのでしばしば規則を破られる点。
守らないくても動作するか？

煽りにマジレスするなよ

>>236
genericsは名前に<>があることで判別できる。
プロパティもget/setで判別できる。

こうしてみればJavaの理念は一貫してる。
新しい言語要素を導入するより名前で区別しようってことだな。
これなら今すでに動いているプログラムが、仕様の変更に対応する必要が無い。

インターフェイスも、名前がIで始まるクラス、とかしてくれればもっと良かったんだが・・・

>>234
Java にプロパティはないけど。JavaBeans にはあるが。
あとシグネチャ規約を破ると（原則的には）プロパティと認識されない。

ハンガリアンは命名の仕方がまずいだけでなく、
宣言や定義を見ればいい情報を再び書かなきゃいけないのが良くない。
メソッドを長々と書く人は何型だかわからなくなるのかも知れんが。

プロパティーが必要な理由と、
genericsがリフレクションで区別されるべき理由を教えて欲しいんだけど・・・

何と比べて、
どんなメリットがあるのか
わかりやすく教えてくれる神はいませんか？

厨房でごめんなさい。

口で言って判るようなメリットはさ、単なる売り口上でさ、　実際はメリットじゃない事が多いんだよ。


だからプロパティのメリットが知りたいなら、プロパティのサポートされた言語を使って体得するのが一番さ

ただし生兵法は怪我の元で、ちょっと齧ってダメとかいうのは止めてね。

つまりVB.NETこそ体験すべき言語と

> 口で言って判るようなメリットはさ、単なる売り口上でさ、　実際はメリットじゃない事が多いんだよ。
簡単に言うと、説明できないって事ですか

>>245
Delphiでもいいです。

>>242
gotoがあればcontinueもbreakもいらない。
足し算があれば掛け算はいらない。
必要ないものを消していったらほとんどのものはいらない。
厨房にはまだ分からんかも知れんが。

違いのよくわかるソースコードjava版とDelphi版をあげて
もらえるとわかるかもしれないのですが・・・

>>248
それは「必要な理由」になって無いな

>>248
Java には goto 無いよ。予約語のリストの中には入ってるけど。

>>249
for(i=0; i<10; i++) {
if(i == 5) break;
}

for(i=0; i<10; i++) {
if(i == 5) goto A;
}
A:

たいして違いは無いね。だから？

>>250
ためしにbreakが必要な理由を教えてくれ

>>253
質問に質問で返すのはルール違反だよ。

>>252
求められてるのは break と goto の違いでなくてプロパティの有無でしょ。

>>254
質問じゃなくて、相手を考えさせようとする手段。
コーチングでは一般的な手法。

まぁ厨房はなんでそうなっているのかもう少し考えろってこった。

>>256
いや、プロパティが無いからJavaは糞って言う連中がいたので
プロパティが有ると何が良いのか知りたいんだけど。

>>258
言葉づかいがすっきりとなる。

>>258
そういうくだらない煽りは無視してください

プロパティは有用だけど、今さら Java の言語仕様を変えてまで追加されても困る。
IDE の進化で getter/setter メソッドの作成も手間ではないし、
プロパティという仕組みがないことで開発コストに影響するほどでもない。

で、Generics の話はどうなった。

Genericsもプロパティと同じでいらんよ。
ためしに両方で書き比べても対して利点は無い。

>>258
たとえばbreakが無くてもgotoがあれば困らない。
逆にbreakがあると何か良いことがあるかと聞かれても、gotoで満足してる人たちにその有用性を説いても理解してもらうことは出来ない。
だけどbreakが無くて全部gotoで済ましちゃう言語は、Javistからみたら糞だろ？
処理が明確にならないとか保守が大変とか猿がスパゲッティ作るとかの理由で。
同じようにメソッドがあればプロパティが無くても困らないが、
プロパティのある言語使いから見ると糞といわれてしまうかもしれない。
が、そんなことに一々反応する必要は無い、各言語の特性を最大限に活用する方が大事。

>>263
>だけどbreakが無くて全部gotoで済ましちゃう言語は、Javistからみたら糞だろ？
別に？

gotoの欠点も知らんのか･･･。

>>263
goto には詳しいらしいけどプロパティには詳しくないのか？

ごめん、genericsあると糞コードが出来るって、たとえばどんなの？
もうオヤジなのでコレクションのキャストが要らなくなるウマー、くらいしか想像できんのだが．

厨房の次はオヤジか。

皆さんがんがって議論してますね〜

プログラマーの多くがソフトウェア開発について、様々な手法や理論を語る。
が・・・概して言えることは、
理論家は口だけで、実際にソフトウェア生産に貢献していない場合が多い。
何故ならピンキリのプログラマが協調して効率よく開発を進めるのに、
理論は時として足かせになるからだ。

開発手法について議論は大いに結構。
しかし、口では語れないこともある。
結局、良質のソフトウェア技術者になるためには、様々なソフトウェアのコーディング
経験を積んで、体で理論を越えた職人気質を知ることが最も重要だ。
そして、職人気質の極みに近づくことはできても、到達することは永遠に無いことを知ろう。

そして、わしの言うことの意味は、結局議論と実践積まないと解らんので、
ここに書いても無駄だなぁと思った。

>>266
プロパティはオブジェクトの特性の設定・取得を明確に出来る。

C#のプロパティはあってもなくてもあまりかわりませんよね。

認識できない奴にはいくら言っても無理か。

結局、JAVAでsetter/getterするのに対するメリットをいえてないからね。

goto厨にbreakのメリットがわからないのと一緒だな

C#のプロパティはsetとgetでアクセシビリティを変えられないので糞。

後藤はどこにでも飛ぶから、訳わからないうどんが出来る。breakはブロック抜けるだけに限定されてそれをふせげる。
setter/getterはなんでも出来るから訳がわからない○○○ができる（？）。プロパティはＸＸＸＸＸだけに限定されてそれをふせげる。

埋めてくれよ、天才。

高速化/単純化するために制御構文で決められた以外の場所に飛びたければ goto が必要。
XXXXしたければ プロパティが必要。
でも良いよ。

JAVAで高速化のためにgoto?
ネタですよね？

>>277 の一行目は二行目のサンプルだよ。
そもそも Java に goto が無いのは知ってるけど。
誰かさんが goto と break に拘るので。

プロパティのメリットまだあ？

何かを強制したり、その機能でなければ実現できないことがなければメリットが無いってわけじゃないだろ？
俺としては>>270は十分なメリットだと思うよ。
別にこれをメリットと思わなくてもかまわないと思うけど、263のように、それを説くだけ時間の無駄。

メリットがあるからJavaにも取り入れれって話にはならないと思うが。

何が出来るとかいう訳じゃなく、区別するといいね、かっちり区別を強制できるわけじゃないけど、
つうことね。それならなっとく。
つまり　_言語の機能_　としてはまったく未熟ということでＦＡ？ＦＡ。

>>282
そんなところ
強制できる技術が発達したら面白いがそれじゃ使い物にならんしな。
代入するときに閉じカッコ書かなくていいのはうれしいが、コストの見落としとかのデメリットを考えると要らん機能ではある。

ちなみに俺はGenericsにも反対なんだがそろそろ話題を元に(ry

で、genericsで出来る糞コードってどんなのよ．

>>225
> メソッドの頭に「get、set」がついてたらプロパティだなんて糞アホな仕様だと思わない？
> メソッドの頭に「test」がついてたらunit test用メソッドだなんてみっともないと思わない？

ソースコードのメソッドなどの手前に [TestFixture]や[STAThread]をつけるなんて
ソースコードを汚染させる糞アホな仕様でみっともないと思わない？

NUnitでTestメソッドの前に[Test]をつけるなんてまるでFortran77のソースコードみたいで
みっともないと思わない？

interface名の頭にIをつけるのC#はみっともない仕様だと思わない？



> クラス名に「<〜>」が入ってたらgenericsクラスだなんて嘲笑激藁な仕様だと思わない？
C#にはGenericsはまだ搭載されていないのに比較しても意味がないと思わない？

Javaにはdelegateがないからgenericsもまともに活用できない

>>286
delegateがあるとどんなメリットがある？

>>240
> インターフェイスも、名前がIで始まるクラス、とかしてくれればもっと良かったんだが・・・
継承時にextends, implementsと記述して区別しているのでわざわざそんなものはいりません。
C#はinterfaceもclassも:で統一したので苦肉の策をとった糞仕様です。

>>285
おいおい、あまり暴走するな。
J2SE1.5の仕様を予習しとけ。

>>286
お前ははコレクションをつかうのにわざわざdelegateを使うのか。

>>285
いずれもC#の仕様ではなくてCLIの仕様だとだけ言っておこう。

>>290
ﾌﾟ。generics = Coolectionか。
こりゃまた物知らずが現れたな。

285
> ソースコードのメソッドなどの手前に [TestFixture]や[STAThread]をつけるなんて
つけなくてもいいよ。
でもつけないで作ったらどうなると思うかな？

つーか、genericsを活用したいなら関数型言語でもやっておけ。
所詮はParametric PolymorphismがJava/C#でも使えます、ってだけだから。

そういう意味合いでしょ？> 286

>>292
また勝手に解釈して。厨房は。死滅スレ以外で煽るな。
Genericsのメリットの一つはコレクション系の操作が楽になることだろ。
まずお前に聞きたい。delegateがないとGenericsもまともに活用できない理由を説明しろ。
delegateがないとGenericsでコレクション系を取り扱ってもまともに活用できない
理由とその事例を説明しろ。

>>294
Lispをやってどうする?

> Genericsのメリットの一つはコレクション系の操作が楽になることだろ。

うははは。すげー馬鹿。

>>293
> 285
> > ソースコードのメソッドなどの手前に [TestFixture]や[STAThread]をつけるなんて
> つけなくてもいいよ。
> でもつけないで作ったらどうなると思うかな？

つけなくても結局他のファイルにその情報を記述するなら
ソースコードのメンテナンス性が悪化するだけではないと。

>>297
煽り厨は氏ね

>>295
Function as Objectを実現できない

煽りも叩きもどうでもいいから
マジでdelegateを使ったGenericsの活用法を知りたい。

なんでこのスレにC#厨やVB厨が邪魔しているんだ？

>>300
"as" という文字列がいかにもVB厨臭くて失笑。

これだから教養の無い奴は（苦笑

Java厨はFunction as Objectなんて知らないのだから。

>>295
関数オブジェクト　がgenericsでどう活躍するのか説明キボン。

そして、OO概念であるintrfaceではダメな理由も．

さらに無知ぶりを発揮。

知ったか君が入って荒れてきたな。
説明できないんだったら消えてイイよ．
この世から。

お前らが煽るからほんとに消えちゃっただろ。
ぜひ説明してほしかったのに。

無理無理．どうせ知ったか君は説明なんて出来ないよ。
煽りだけの知ったか君は消えてよし。その存在自体が。

http://pc2.2ch.net/test/read.cgi/tech/1054523453/79

ところでJavaだとコレクション以外にGenericsの使い道が無いように思うがどうよ。

>>313
>>1　曰く邪悪なことが出来るそうだが…。おれはどういうのなのか浮かばん。

>>301
F#そのものがそのサンプル

Delphiの場合は高速コンパイルを維持したままRAD-IDEとのコンビネーションがとても旨くハマッタけどJAVAだとどうかな

JAVAの文法でプロパティを入れてもC#みたいになるだけで、メリットが見えないよね。

> Delphiの場合は高速コンパイルを維持したままRAD-IDEとのコンビネーションがとても旨くハマッタけど
てきとーな事言って誤魔化しているな。

確かに意味不明

意味判んない？
　 Delphiは published + property を使ってる。
　　pubished というのは実行時型情報を　持ちなさいという指令だ。

コンパイラは、published な property やメソッドについて型情報を保存する。
この情報を使って IDE は　簡単にプロパティエディタを表示出来たわけだ。
そして、名前だけでなくシリアライズ時に保存量を減らせるように初期値のような情報を追加するとか
そういう拡張をコンポーネントという仕掛けを通じて出来た。Get/Set方式ならこれは出来なかったろう。

またDelphiのプロパティはC++ のようなinline の代わりにもなっていて、プロパティへのアクセスは
非常に軽い。　　もしGet/Set式だと イベント呼び出しの負荷は倍になってた訳で、その意味だけで
も当時は採用べき理由になったのだろうと思う。

>>319
>>316がそういう意味だと言うつもりかね。ﾌﾟﾌﾟﾌﾟ

Delphiなインターネットはここですか？

結局.NET使いに言い負けてしまったか

>もしGet/Set式だと イベント呼び出しの負荷は倍になってた訳で、
0.0000000001秒くらいだけど。
コンパイラで最適化できるけど。

>この情報を使って IDE は　簡単にプロパティエディタを表示出来たわけだ。
Javaもできるけど・・・

>名前だけでなくシリアライズ時に保存量を減らせるように初期値のような情報を追加するとか
>そういう拡張をコンポーネントという仕掛けを通じて出来た。Get/Set方式ならこれは出来なかったろう。
はぁ？

>Function as Object
Interfaceに対するメリットをどうぞ

Function as Objectの一例。
Javaでやるとどうなる？

using System;

delegate T0 Function<T0, T1, T2>(T1 arg1, T2 arg2);

class Test {

　　// 引数をトレースするだけ
　　static object Func1(int n1, int n2) {
　　　　Console.WriteLine("n1 = {0}, n2 = {1}", n1, n2);
　　　　return null;
　　}

　　// 引数を足して返す
　　static int Func2(int n1, int n2) {
　　　　return n1 + n2;
　　}

　　static void Main() {
　　　　Delegate[] func = {
　　　　　　new Function<object, int, int>(Func1),
　　　　　　new Function<int, int, int>(Func2)
　　　　};

　　　　object[] param = new object[] { 3, 5 };
　　　　foreach (Delegate d in func) {
　　　　　　object retval = d.DynamicInvoke(param);
　　　　　　Console.WriteLine("return value : " + retval);
　　　　}
　　}
}

念のため実行結果。

n1 = 3, n2 = 5
return value :
return value : 8

interface Func{
int function(int a,int b);
//Object function(Object a,Object b)でもいいけど、それは設計レベルの話
}

class Func1 implements Func{
function(int a,int b){
return a+b;
}

class Func2
{(ry
}

FunctionFactory(ry

以上
デザパタ知ってればわかるっしょ。
ちなみに、そこであげられてるのはgoto的な要素があるので
やろうと思えばできるけど、普通はしない。
intが返ってきたり、objectが返ってきたりするようなのを
ポリモしないんで。
そうなってるなら、設計がクソで
すなわち破綻を意味する。

あ、ちなみにT0,T1,T2
の代替になる物があるかと言われれば
instance of
というのがあるからね。
まあ、普通は使わない。

>>329
意図が分かってもらえなかったかな？
引数・戻り値の型が色々変わった時にどうするという話。
引数も戻り値もint固定なら、わざわざgenerics使うアフォはいないわけで。

C#でそのサンプルは無理があるんでねーの？
F#はコンパイル時に型推論に基づいて適切なFuncion<>型を作るわけだから。
プログラマが自分からFuncion<>型を作ることはしないし。

delegateがないと、なんでこれができないんだ？？？？
genericsだけ在れば良いんじゃね−の？

>>333
delegateも所詮は型なんだからその通りだと思う。
C#はシンタクスシュガーでメソッドをオブジェクトのように扱ってる「気になれる」だけ。
こういうのね。

Function<int, int> f = new Function<int, int>(SomeFunc);
int result = f(100); // ←これね

closureもどきを作るならdelegateの方が楽なのもまた事実。

.NET 2.0ならこんなことも出来るし。

Function<int, int, int> f = new Function<int, int, int>(n1, n2) = {
return (n1 + n2);
}
int result = f(10, 20);

で、Genericsのせいで、厨が書いて困るようなコードってどんなのよ？ >>1

ここはJAVAスレじゃないのか？
ドトネト厨のオナーニはまだ終わってないのか？

78 名前：デフォルトの名無しさん 投稿日：2003/06/15(日) 01:37
>>69
それは、たとえばEJBとかでは使えんなぁ。
さて、何故でしょう？わかった人は初心者卒業。


何か調子に乗っているが皆から黙殺されているのが笑える。

Java厨はgenericsを使ってないようだ。
.NET使いの方が上。

>>326
java.lang.reflect.Methodと何が違うの？
ただのSyntaxSugar？コンパイルしていないのでだれか検証よろしこ。

class Test {
　static void writeLine(String format, Object[] args) { System.out.println(MessageFormat.format(format, args)); }

　static Object[] args(int n1, int n2) { return new Object[]{ new Integer(n1), new Integer(n2) }; }

　static Object Func1(int n1, int n2) { writeLine("n1 = {0}, n2 = {1}", args(n1, n2)) }

　static int Func2(int n1, int n2) { retur n1 + n2; }

　static Object[] toObject(Object array) {
　　int size = Array.getLength(array);
　　Class type = array.getClass().getComponentType();
　　if(type == int.class) type = Integer.class;
　　Object ret = Array.newInstance(type, size);
　　for(int i = 0; i < size; ++ i) Array.set(ret, i, Array.get(array, i));
　　return (Object[])ret;
　}

　public static void main(String[] args) throws Exception { // <- C#風
　　Method[] m = {
　　　Test.class.getMethod("Func1", new Class[]{ int.class, int.class }),
　　　Test.class.getMethod("Func2", new Class[]{ int.class, int.class }),
　　};
　　Object[] param = toObject(new int{ 3, 5 });
　　System.out.println(m[0].invoke(param));
　　System.out.println(m[1].invoke(param));
　}
}

この例でさえ一時オブジェクトが大量につくられるのは、C#＞Javaなんだけどね。
ところで、.NETだと、OutputStreamのポリモーフィズムってどうやってんの？（ｗ

ソースの行数は圧倒的にC#の方が少ないな。

>>344
あたりまえでしょ（ｗ

StringクラスとJDBCが無い状況では、デザインパターンそのものが違う形で生まれていたはずだし。

どうでもいいがJava陣営はgenerics使いたがらないな。(w

>>345
あたりまえでしょ（ｗ

　　　　　　new Function<int, int, int>(Func2)
ここと

　　　　object[] param = new object[] { 3, 5 };
ここと

　　　　foreach (Delegate d in func) {
ここと

見えないコードが大量に動いているので、、、、
なんならC#エミュレータJavaで作ってみますか？ｗ

>>346

Typesafeに慣れてるので、ちょっとGenericsは恐怖。

Javaの理念としては、
便利であっても悪い癖を助長する機能は省くってのがあるからね。
それに賛成しているので、

よくqsortに渡す_cmp関数でSIG-SEGV起こした記憶もあるし。

ところでJavaのgenericsってメソッドのみでの型パラメータは使えるの？

class Hoge { // ←ここではパラメータなし

　　public void HogeHoge<T>() { // ←メソッドでパラメータを取る
　　}
}

>>344
記憶しなきゃならないルールはJavaの方が少ないな。（ﾊｹﾞﾜﾗﾌﾟ

>>349

意味不明だな。
genericsは、Templateなので、、、

インターフェースの方が100倍堅牢だぞ

ちなみにC#では>>349はOK。

Hoge h = new Hoge();
h.HogeHoge<int>(0);
h.HogeHoge<string>("Hello");

Javaのgenericsは中途半端で使えないことが明らかになったようだ。
C#の方が柔軟で強力で、generics対応のソースも公開されてるし。

>>352

結局内部で、object.ToString 呼び出すなら同じでは？
インターフェース使え


来るんじゃねえ
ターコｗ

.NET2.0 > SSCLI + gyro >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> J2SE1.5

>>355

Win95でも動けばな

やっぱり.NETの方がエレガントだね。
Javaは破綻してる。

J2SE1.5

プロパティのない糞仕様
使えないgenerics
C#の後追いながらも中途半端で劣るforeach、enum、metadata、auto-boxing

>>357

まぁあれだよ。
美しいってのは、
自分の無能力に対する恐怖をやわらげるわけだ、

そしてVB.NETに3年遅れて今さら出てくるProject Rave

>引数・戻り値の型が色々変わった時にどうするという話。
何度も書いてるけど、キャストでどうにでもなるんだって。
コンパイル時の文法チェックがつくだけで、
それがどうした？
となるわけだ。
アセンブラ使った事ある人ならわかるんだけどね。

>>358
それはC#になれたユーザを囲い込みたいだけなので、プログラムの本質とは離れると思うが

Javaってほんと糞だな。

>>363

まったくもって、
Microsoftにたったの30日でぱくられるなんて、
まともな実装はMicrosoftでさえ完了出来てない。

思想自体たこなんだな

>プロパティのない糞仕様
>使えないgenerics
>C#の後追いながらも中途半端で劣るforeach、enum、metadata、auto-boxing
キャストを無くすgenerics以外は特に欲しい機能ないな・・・

>>363
糞だからMSに徹底的に修正されて出来たのが.NET。
悪いけどJavaはもう一度ゼロから作り直さないと.NETには勝てないよ。

>>366

ひょっとしてテキストエディタでEJBとかやってませんか？ｗ

J#でswingが使えるんだって。
http://msdn.microsoft.com/vjsharp/supui/
SWTも使えるし、もうJavaやる理由なんてないよ。

とりあえず、

コンパイルしたバイナリを保存する機構を用意してくれ、、
ClassPathとかClassLoaderあたりにその機能を追加してほすぃ

>>358
正しくは、他言語ほどには使えなくした Generics なんだけどね。
Java は馬鹿のための道具と言いたければ言いねえ。
それでもプロジェクトは進めなきゃならん。

http://homepage.mac.com/hiroyuki44/

Java使って書いたコードが
J#でも使えるの？
だったら、JAVAで書いて
気が向いたらJ#でコンパイルしてあげてもいいかな。

今 日 も 沢 山 釣 れ た な

　禿藁ﾌﾟ

CLIってSIG-SEGV出るんでしょ？

禿藁ﾌﾟ

>>358
enum は Java の方がいろいろ機能があるね。
http://jcp.org/aboutJava/communityprocess/jsr/tiger/enum.html

実は整数型ってゆー .NET の enum は個人的に好きじゃない。

今のJavaはかつてのVBを見てるような気分だ。
付け焼き刃状態でどんどん機能追加してるが根本を変えないと駄目な状態。

今年からマイクロソフトを見習って宣伝部員の雇用拡大。

あまちゃんプログラマーと糞上司を安心させるための
精神学者によるマニュアル・UI設計をはじめたいと思います。

禿藁ﾌﾟ

>>376
まあ、否定はできない

>精神学者
？

まぁ、

Classが、Object派生してたり、
Methodが、Object派生してたり、

ClassクラスにReflection出来たり、

Javaは素敵でしたよ。昔はね、

いや、なんとなくリンク辿ってみたら、Enumもそうなのかって感動した

>>379

作ったプログラムを実際にアマチュアに動かしてもらって
心電図とったり顔の表情とかしぐさ観察するってやつ。

「最新のOfficeでは以前のOfficeに比べて作業効率が改善します。」
っていう宣伝文句を裏付ける為にも必要だと思うよ。

でもintはObject派生してない糞仕様

心理学とか神経学じゃなくて精神学なの？
聞いたこと無いけど。

精神分析学はそーゆー事やらんと思うし。

C#も同じでしょ？
Boxing、Unboxingなんていう、頭ゆるくする機能があるだけ。

System.out.println(int.class.toString());

>>383
アメリカ人は勝ち負けにこだわるので適当に造語しただけ、

日本語では心理＝甘えって捕らえ方だからね

おねがいしま〜す♪
http://www1.free-city.net/home/kotarou/page003.html

>>385
ちなみに英語でのスペルは？

学問的にはともかくとしてだな、、、


心理より精神の方がやっぱり近いと思うぞ…

mental; spiritual; moral.

仕事ではもはや単価廉くてC#なんて冒険やってられないだけどね。

>>384
メタクラスを持っていながらもObjectに代入できないのか。
C#では可能なのに。

Object o = 0;

>>389
精神じゃなくて「精神学」のスペルだよ。

プロパティを採用しない理由を考えてみた。

JakartaのBeanUtilだと、

alice.bob.carol

これは、

get("alice").get("bob").get("carol")
でもあるし、
getAlice().getBob().getCarol()
でもあるし、
getAlice().get("bob").getCarol()
でもある。

プロパティいらね

「精神観察」に格下げしておくよ

>>372
J2SE1.4以降のみにあるクラスライブラリで書いたコードすべてがJ#で使えるとは思えないが。
RMMIもJ2EEのクラスも使えないんだったら必要性感じない。

>>391

ふーん。

Object A = 1;
Object B = 2;
Object C = 3;

A + B + C はどうなるの？

>>376
そいつはC#ではないかと。VB厨がC#厨になんとかすばやく昇格できるようにと

クラスといったオブジェクト指向、そしてデザインパターンだけでできるものを
foreach,set/get,delegateといい
わざわざ言語のシンタックスとして追加したC#は失敗だな。ﾌﾟ

>>394
「精神観察」ってググっても7件しかヒットしないぞ。

>>391

もうひとつ教えてくれ、以下のコード、C#で書き直すとどう動くんだ？

Object[] target = { 1, 2, 3, new Integer(4), new Integer(5), 10.0 };

for(int i = 0; i < taget.length; ++ i) {
　System.out.println(i + " : " + target[i].getClass());
}

>>390
C#の案件もJavaの6分の1くらいだし

>>396
コンパイルエラー。

>>399
そうそう、そういう意味で使った

>>402
馬鹿じゃねーの（プ

C#のプロパティもdellegateも落ちこぼれVB厨を救うために作られた糞仕様
最初から使用禁止にしておけばもっとエンタープライズ規模なプログラミングを効率よくできたものを。

90 名前：デフォルトの名無しさん 投稿日：03/06/22 02:31
スレと関係ないんだけどさ、俺「釣り」とか「釣り師」っていうのは、
　　　釣り師→　○　 ／|←竿
　　　　　　　　　　ト／　 |
　　　　　　　　　 │. 　~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
　　　　　　　　　 八　　 §←餌(疑似餌)　　　　　>ﾟ++<

の組み合わせだと思ってたんだけど、
最近自称釣り師がダイレクトで自分の本音を攻撃されて「釣れた！」とか
言ってるの多いよね。
　これは、どっちかというと、

　　　　　　..釣れたよ〜・・・│
　　　　　　────y──┘
　
　　　　　　 ・ﾟ･｡ ○ﾉノ。・ﾟ･
　　　　~~~~~~~~~~│~~~~~~~~~~~~~~~
　　　　　　　　　　　ト>ﾟ++< ミ　ﾊﾟｸｯ
　　　　　ｼﾞﾀﾊﾞﾀ 　ハ
　　　　　　　　　ノ　ﾉ

>>400
C#にIntegerだのSystemクラスはありません。

>>407
書き直せよ

C#だとintはObjectだな

>>403
で、「精神観察」のスペルは？

>>353
> Javaのgenericsは中途半端で使えないことが明らかになったようだ。
> C#の方が柔軟で強力で、generics対応のソースも公開されてるし。
genericsはC++のほうがもっと柔軟なわけだが。
その結果混乱を招き各プログラマ思い思いの
身勝手な腐ったソースコードが散乱してしまったわけだ。

コーディングに対する柔軟性に重きを置いたはいいが
コードの可読性を低下させ拡張性を軽く見ていたため
余分に修正を加えるはめになる罠。

その点、拡張性、汎用性という点ではJavaのほうが柔軟性が高い。

http://honyakuinfoseek.infoseek.co.jp/amitext/indexUTF8.jsp

によるとMoral observation
らしい。

まぁ、ユーザーとのセッションみたいなものだろうな。

class Test {

　　static void Main() {
　　　　System.Object[] target = { 1, 2, 3, new java.lang.Integer(4), new java.lang.Integer(5), 10.0 };

　　　　for (int i = 0; i < target.Length; ++i) {
　　　　　　[email protected](i + " : " + target[i].GetType());
　　　　}
　　}
}

0 : System.Int32
1 : System.Int32
2 : System.Int32
3 : java.lang.Integer
4 : java.lang.Integer
5 : System.Double

>>334
> Function<int, int> f = new Function<int, int>(SomeFunc);
> int result = f(100); // ←これね
ソースコードを反って読みにくくしているだけじゃないかと。
C＃厨の大好きなスパゲティコードは消えてくれ。

>>413
なんでそれで、

Object A = 1, B = 2, C = 3.0;

A + B + C が計算できないわけ（？＿？；）

>>414
スパゲティコードの意味が違うような。
むしろ>>334は短くなってるわけだし。

>>415
Object型に＋演算子定義がないから。

>>417
所詮付け焼刃

>>415
error CS0019: 演算子 '+' を 'object' と 'object'
型のオペランドに適用することはできません。

これならOK。

object o = (int) A + (int) B + (int) C;

なんだか、C#は後だしじゃんけんに勝ったつもりでいるようだけど
Javaにとって反面教師になっているみたいだね。

2chに対抗して西が一部有料課金制の1chを作ったはいいがうまくいかず、
スポンサーで運営費を賄っているひろゆきに馬鹿にされている姿が目に浮かぶ。

>>326
メソッドがstaticになっているのが気に入らん。
オブジェクト指向が生かされていない。

> Function as Objectの一例。
> 　　static object Func1(int n1, int n2) {
> 　　　　Console.WriteLine("n1 = {0}, n2 = {1}", n1, n2);
> 　　　　return null;
> 　　}
Object型なのにnullを返すのも気に食わん。
最初からvoidにしてすっきりさせろ。

>>413
なんかだましてないか？

System.Int32で検索したらこんなのが出てきた。

IConvertible インターフェイス

実装参照の値または値型を、値と等価な共通言語ランタイム型に変換するメソッドを定義します。

object[] target = { 1, 2, 3, new Int32(4), new Int32(5), 10.0 };
これが可能であればJavaの域を越えてはいないな。ただのSyntaxSugar

>>422
いいところに気付いたね。
genericsでSystem.Voidは使えないのだよ。
だからnullをunit代わりにしてる。

>>423
もうひとつ追加ね。

int x = 18;
x.getType() <<- ここでBoxingが起きるなら最悪

>>417
> >>415
> Object型に＋演算子定義がないから。

C#のboxingUnboxing変換ってホント意味がないな(w
Javaよりコードが短いからいいっんだって？

最初から例外も返してくれないC言語のバッファオーパーフローのように
知らない間に思わぬエラーに巻き込まれて大変だな(藁


結局>>420のようにコード量が増えて
あとあとで気にすべきことが多くて意味がないじゃんw

>>423
IConvertibleは関係ない。

以下証拠
IL_0000: ldc.i4.6
IL_0001: newarr [mscorlib]System.Object
IL_0006: stloc.2
IL_0007: ldloc.2
IL_0008: ldc.i4.0
IL_0009: ldc.i4.1
IL_000a: box [mscorlib]System.Int32
IL_000f: stelem.ref
IL_0010: ldloc.2
IL_0011: ldc.i4.1
IL_0012: ldc.i4.2
IL_0013: box [mscorlib]System.Int32
IL_0018: stelem.ref
IL_0019: ldloc.2
IL_001a: ldc.i4.2
IL_001b: ldc.i4.3
IL_001c: box [mscorlib]System.Int32
IL_0021: stelem.ref

　今　日　も　沢　山　釣　れ　た　な　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　禿藁ﾌﾟ

>>427
↑
墓穴を掘ってしまった
蛸宣伝ｼｬｲﾝ

>>425
起きる。値型から参照型にしてからObject.GetType()を呼び出す必要あり。

IL_0000: ldc.i4.s 18
IL_0002: stloc.0
IL_0003: ldloc.0
IL_0004: box [mscorlib]System.Int32
IL_0009: call instance class [mscorlib]System.Type [mscorlib]System.Object::GetType()

ようするに、

operatorは、オブジェクトでもないし、メソッドみたいに継承できるものでも無いんですね？

public operator + (object b) {
　if(b instanceof ValueType) {
　　return (int)this + (int)b;
　}
　throw new SIG-SEGV;
}

>>430

Javaでｲｲや。（藁

>>1
genericsよりもC#にあるdelegate, set/getがJavaにそっくりそのまま移植されたら
VB厨のようなスパゲティ厨房が増えて困ってしまうな。

純粋なOOで逝くか、Genericで逝くか、それが問題だ！

つー悩みは、まぼろしです。

手段が多いほうが好みの人は、Genericやればいい。
保守性が好みの人は、OOでがんがればいい。

大体、どっちがいいかでケンカする連中は、自分一人
でコーディングすることしか考えない社会人プログラマ
3〜5年目ってとこだろ。

メシ食うためにいかに生産性を上げるか考えるように
なったらこんな議論が些細な問題のひとつに過ぎない
ことを知るだろう。

訂正訂正、

やるなら↓かなぁ？

object operator + (object b) throws ClassCastException {
　return (object)((int)this + (int)b);
}

>>431
なに？　演算子のオーバローディングできない？

メソッドでじゅうぶんじゃねえかと。


java.lang.BigDecimal
java.lang.BigIntegerをいじくりまわしているほうがええっす。

>>431
継承できるメソッドだよ。

>>434
コーディング基準を決めるときはどうするんだyo!

>>434
そういう話はわかりきった事なので、あえてここでは取り上げてない。

来るんじゃねー
ターコｗ

>>436

それ遅いから使わないよ。

俺は、StringBufferでやってる。（爆
Formatクラスも簡単に作れるし、Mutable問題はパフォーマンスに影響するから。

>>434
いやまて、Genericsなしでは、
コレクションを使うときわざわざinstanceofを使う羽目になることがある。

instanceofはオブジェクト指向的じゃなさ過ぎる。
Genericsは使い方によってはオブジェクト指向らしさが増すはず。

というか、
SmallTalkをﾁｮｯﾊﾟﾔにするVM欲しくなったぞ。

>>440
誤差の丸め方法まで作っているのか？
あれなしで多倍長高階関数を作るのは面倒くさい。

>>434
開発プロジェクト要素（動作環境・要員のスキル等）を判断してプロジェクトリーダの俺が決める。
商業開発の場合だけどね。
そうでなきゃ、ケンカして強いやつが仕切ればいい。
あるいは、ひとりでがんがれ。

>>439
ごめんな。ついつい議論が面白くって。
まあ、本当にわかりきったことなら、おたくがここに居る
のは俺と同じ道楽ってわけだ。

俺と同じく、来るんじゃねーと言ってみるｗ

>>443
誤差？

そんなのあった？

桁落としならやってるけど。

アラン・ケイ氏，大いに語る

藤枝：Smalltalkが狙ったオブジェクト指向の実現という意味では，Javaがその
役割を果たしているのではないか。

ケイ：いや，まったく違う。Javaについては，いろいろな見方があるが，本来は
アプライアンス製品用の小さなプログラムで，インターネット用にデザインされた
ものではない。だからいろいろと問題がある。サン・マイクロシステムズは
PARC出身者を採用しているが。

藤枝：マイクロソフトの.NETはどう思うか。

ケイ：.NETのほうが，Javaよりはいい。

藤枝：本当に？。

ケイ：本当にそう思う。.NETは優れたアプローチ方法だ。マイクロソフトは
今のままのシステムを今後20年間持続することはできない。そこで，だれか
利口な人がいてもっと安定したプラットフォームを作ろうと言った。安定した
プラットフォームを求めた結果生まれた.NETは，よく見るとSmalltalkに似ている。
Javaよりレベルが高い。よくコントロールされたプラットフォームだ。Excelや
Wordをその上で動かそうというのは優れた戦略だ。

藤枝：うまくいくだろうか。

ケイ：何千人もエンジニアがいるから，やり抜くだろう。

>>444

それはどうも、眠くなったので俺は、もう来ません。

http://homepage.mac.com/hiroyuki44/

Windowsでしか動かない事に非常に恐怖します。

MSは技術的には優れているけど、高い芸術品と同じなので、
経済的にみなが行き詰まると思われます。

Delphi,Java,C#、作った人間同じなんだけどね。
JavaよりC#が優れているのはあたりまえ。
Javaエンジニアの持っていた改良案をSunが破棄したうわさをかぎつけたMSが引き抜いた。

アヒャ。
自己レスになってるー（汗

>>444の訂正。
×　>>434　→　>>438


>>441
instanceofは俺も使いたくない。
おっしゃるとおりッスね。
でも世の中完全なもんなんてないし。
お好みで両刀使いもいいんじゃないですか。

てなわけで、もう来ねぇよ。ｳﾜｰﾝ。

このスレ見てるとJavaのgenericsじゃなくてC#のを覚えてしまいそうだ。

>>449
DelphiとC#は同じでもJavaはちがう。

もしや！　ゴスリングとヘジルスは同一人物だったのか！

>>452
引き抜かれたのは、某Javaエンジニアだよ。間違えない

>>449
> Delphi,Java,C#、作った人間同じなんだけどね。
某から引き抜かれた Anders Hejlsberg じゃないっすよね。
誰だろ？

>>445
BigDecimal#divide(BidDecimal 割られる方, int 小数点以下の桁数, int 丸めモード)

この丸めモードのこと。BigDecimal.ROUND_HALF_EVENとか。
精度を保つためROUND_HALF_EVENをよく使っている。


「桁落とし」という紛らわしい用語はやめれ。
まるで災難の一種「桁落ち」みたいだ。「切り捨て」のことか？

>>453
藻前はヘジルスがJavaエンジニアだとでもいいたいんちゃうか？

ヘジルスがJavaを全く知らなかったらC#なんてJava似の言語は作れなかっただろう。
そんでJavaに熟知したヘジルスのことをJavaエンジニアとも比喩してるってことか。

>>455
比較するときの話だと思ったよ。
double a, b, c;

if(a == b || (a - SPAN <= b && b <= a + SPAN))

某Javaエンジニア = 某ランドのJavaエンジニア = ヘジルスバグ
なるほど

>>457
畜生！！
開き直ってやる。
間違えてましたー。

だけどBorlandにもJavaエンジニアは居ますー。BlackDownパクリましたー。

hage

> Delphi,Java,C#、作った人間同じなんだけどね。
ってのはどーなったんだ？

>>458
機械エプシロンはそんな使い方するよりもっと効率のよい方法がある。

>>460
> だけどBorlandにもJavaエンジニアは居ますー。BlackDownパクリましたー。
そりゃJBuilderが会社の存亡を握っているような会社だからねえ。

>>462
間違えなのかー。
.NETが出た当時、ZDNETに掲載されていた
　気　が　す　る　。

　モ　マ　イ　ラ

　と　こ　ろ　で　

　G　e　n　e　r　i　c　s　は　

　ど　う　よ　。

機械エプシロン


/*
1より大きい最小の不動小数点と1との差　計算機エプシロンとも言う。
*/
#include <stdio.h>
#include <stdlib.h>
int main()
{
float e, w;

printf(" e 1 + e (1 + e) - 1 \n");
printf("-------------- -------------- -------------- \n");
e = 1; w = 1 + e;
while (w > 1) {
printf("% -14g % -14g % -14g\n", e, w, w - 1);
e /= 2; w = 1 + e;
}
return EXIT_SUCCESS;
}



そんなことより、

for(int i = 0; i < 100000; ++ i) {
　x += 1.0;
}

x == 100000.0 の状態が知りたいのだが、
機械エプシロンを100000倍するの？

>>466
instanceofを使いたくないときのためだけに使う。
それ以外では使用禁止。

>>467
どこからかソースこぴったなw
EXIT_SUCESSとかいてるあたりが奥村の「C言語による・・・」にクリソツだなw

いやもう、数値計算を勉強してくださいとしか言い様が無い。

>>469

入社試験の問題でさ、

double配列にランダムな値を入れてあって
どうやって足すと誤差が少ないか？

らしいのよ

>>469
http://www.google.co.jp/search?hl=ja&ie=UTF-8&oe=UTF-8&c2coff=1&q=%E6%A9%9F%E6%A2%B0%E3%82%A8%E3%83%97%E3%82%B7%E3%83%AD%E3%83%B3&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=
一番上のとこからコピペしたみたいですね。

>>470
ソートして小さい奴から足すってのじゃなくて？

しかしみなさん、博学ですな

>>472
その日本語だと失敗だな。
ソート関数書いてみそ。
これ以上このネタは禁止ネ

>>472
正数と負数はわけよう

あ、絶対値って入れなきゃダメって事か。

Genericsはどこいった？？？

>>470
Pack10進法に変換して足す。

>>472
　じゃあ、ほぼ同じ値が沢山並んでる場合はどうなる？

>>472
　じゃあ、ほぼ同じ値が沢村並んでる場合はどうなる？

genericsとOOは混在できないって話の前提をみんな無視しすぎでしょう。
genericsでできる事はOOでもできる。
従って、OOをベースに
genericsをコレクションにのみ適用するのは
すごく賢いやり方だと思うんだけど、どう？

>>481
>genericsとOOは混在できないって話の前提をみんな無視しすぎでしょう。

勝手な前提をつくらないでください。

>>481
猿が、板汚す

>>481
直交する概念だから混在できるって前提だろ……

C++でOOとgenericsを混在させると
えらい事になるのは事実だね。

それはC++におけるOOもgenericsも
Cに増改築した結果取り入れられたものだから。

Javaは最初からOO前提で作られてるから
genericsを取り入れてもC++ほどえらいことにはならないはず。
そもそもC++のgenericsよりもだいぶ制限きついし。

ん？
って事は、結局
Java+Genericsは最強って事か。

このスレを読む限りJavaしかやってない奴は型パラメータを判ってない奴が多いと
「〜でいいじゃん」
とかいうなら「C言語でOOできるじゃん」って話になっちゃうぞ。
コーディングの手間や安全性や保守性を抜きにするなら

>このスレを読む限りJavaしかやってない奴は型パラメータを判ってない奴が多いと
おまえがOOをわかってないだけなんじゃない？
instance of って知ってる？
ポリモーフィズムって知ってる？

>「〜でいいじゃん」とかいうなら
メリットを挙げないから、それで終わるんじゃないかと。
レスを上から下まで読んだけど、
誰も具体的にメリットを説明してないけど。

OOとGenericsは関係ないとあれほど

>489はバカ

>おまえがOOをわかってないだけなんじゃない？
>instance of って知ってる？
>ポリモーフィズムって知ってる？

(´ﾟc_,ﾟ` ) ﾌﾟｯ

instanceofを使う奴は白痴

いまさらだけど、、
>>1の文章読みづらい

スレストあげ

instance of なんて
型でif文書いてるようなもんだしなぁ。意味なし

せっかくポリモフィズムやってるのに型ごとに条件分岐なんてしてたらおいしさ半分だと思われ。

型パラメーターってのは全部instance ofで置き換えられるけど、
ポリモフィズムを使うのが普通だね。

型がObjectにまでに成り下がったのなら
もうポリモフィズムも糞もないだろう

Object厨もVariant厨も同じようなもんですね（ｗ

http://homepage.mac.com/hiroyuki44/

JSPのカスタムタグで、ネストされたタグの中からその親タグを判別する時、
その親タグが「何のタグかわからない」ので、結局instanceOfでしか判別できない罠。
ていうかコレって、別にパラメータの話じゃなかったね。

話の流れ無視してスマソ。

ていうか各タグが自身に固有なIDとか持ってれば判別できるじゃんね。
501 のカキコは無視して下さい。

＃ところで素朴な疑問だけど、instanceofのコストってどのくらいなんだろう。

--
public void testInstanceof(){
long s = System.currentTimeMillis();
for(int j=0; j<10000; j++)
for(int i=0; i<65536; i++);
p("none:" + (System.currentTimeMillis() - s) );

Object o = "obj";
s = System.currentTimeMillis();
for(int j=0; j<10000; j++)
for(int i=0; i<65536; i++)
if( o instanceof String);
p("String:" + (System.currentTimeMillis() - s) );

s = System.currentTimeMillis();
for(int j=0; j<10000; j++)
for(int i=0; i<65536; i++)
if( o instanceof Stack);
p("Stack:" + (System.currentTimeMillis() - s) );
}
-- result

none:1312
String:1922
Stack:1922

--

問題にならないほど安いですな

http://homepage.mac.com/hiroyuki44/

http://homepage.mac.com/hiroyuki44/

>>503
1.5倍のどこが安いのかと。

>>506
ただ同然じゃん

>型がObjectにまでに成り下がったのなら
>もうポリモフィズムも糞もないだろう
普通はinterfaceを使うだろ。

http://homepage.mac.com/hiroyuki44/

http://homepage.mac.com/hiroyuki44/

http://homepage.mac.com/hiroyuki44/

http://homepage.mac.com/hiroyuki44/

>>instanceof
Java とは関係ないが CLOS (Common Lisp Object System) だと
型ごとに条件分岐するのが正しいやり方だ。

>>489に加勢

>>491はバカ
> (´ﾟc_,ﾟ` ) ﾌﾟｯ (藁

514==489
> (´ﾟc_,ﾟ` ) ﾌﾟｯ (藁

>>515
はずれ。顔文字が餓鬼っぽいﾌﾟ

ほしゅ

不要という結論で良いのか？

Javaにはプ呂派手ィも印出腐も出理下ー斗も不要。

そんなきのうつけたらC#厨やVB厨のような馬鹿がJavaをやると
ソースコードを汚す。

>>520
お前のソースは汚そうだな

でかいシステムでフレームワークモドキ作ってるオナニー連中が喜びそうだな。
今ですらハッシュテーブルとベクターで汎用バケツ作ってアプリを大混乱に陥れてるというのに。

>>522
>今ですらハッシュテーブルとベクターで汎用バケツ作って
そこにちゃんと型を明示できるようになるからいいんですよ

>523
残念ながらそのハッシュテーブルには文字列が入ったり文字列配列が入ったり Bean が入ったり Exception が入ったり...

>>524
しかしint等は入らない。これがVariantとの違いであり、素晴らしいことだ。

Generics 要らんから、primitive 型もオブジェクトにしてくれ。

Autoboxingっていう機能がprimitive型とラッパークラスの変換してくれるんじゃなかったっけ。

なぜそこまでしてVariant化したいのかわからん。

コレクションの機能を使って何かを纏めてしまっておく時、普通のヤツは
何か意味のある集合をまとめてしまっておくはずだーな。
そういう「あるクラスの機能を利用する」関係の場合は、コンポジション
が基本だよな。

たのむからHashMap継承した俺様謎仕様コレクション（put()とget()が
生公開状態）をフレームワークのValueObjectインターフェイスにしな
いでくれよ、そこの頭でっかちの自称アーキテクトさん。

>>529

うにゃ、

結構、containsKey とか、.keySet().iterator() とか、
list.remove とか、便利だじょ

ぽ

つまりGenericsは必要、とｌ。

Windows版の最新ＪＡＶＡは
http://java.sun.com/webapps/download/Redirect/52201172/27014527-220/j2re-1_4_2-windows-i586.exe
でダウンロードできるよ

ＪＡＶＡが早くなるよ。みんなインストールしよう！

>>529
あー、もち、getAsStringとかgetAsNumberとか無いならゴミだね。それ

Genericsだとひとつのタイプでしょ？
タイプ変換もやってくれると良いのに。

↑ｺﾞﾐ

なんでもObjectに突っ込むアホを防ぐための機能と思ってたが

>>536
なんでも突っ込めるようにObjectにするための機能でしょ。

なんでもアホに突っ込むObjectを防ぐための機能だろう。

Objectがアホになんでも突っ込むのを防ぐための機能じゃないの？

>>530 >>534
コレクションに直接プリミティブとして扱われる値を入れてインターフェイスにして
いるとしたら、そっちのほうが問題だな。

class ValueColleciton{
　private Colleciton implement;
　public Element getElement(検索条件);
　public void setElement(位置指定,Element);
}

class Element{
　int value1;double value2;String value3;などなど
}

とかじゃないのかね。

>>540
基本的にResultSetからElementの配列作ったり、
RequestParameterからElementの配列作ったり、
Elementの値をDBに格納出来るなら、

Collectionはひとつのビューとしてしか存在する必要無いね

>>540のようなアホみたいなクラスを作らないためのGenerics

>>540
キモイ…。

>>529は自称アーキテクトに、日々いじめられてる訳か・・・かわいそ。

遅いレスだが、 >>529
＞ 俺様謎仕様コレクション
は、いいとして、

＞（put()とget()が生公開状態）
凄ェ痛い。(笑

いつ頃からGenericsは使えるの？まだなんでしょ？

C#みたいにこういうことができないと。
http://pc2.2ch.net/test/read.cgi/tech/1046849844/104

>>545
なんで？

class MyCollection extends HashMap{
　public void putMyElement(int,MyElement);
　public MyElement getMyElement(int);
}

なんていう馬鹿なクラス切ってる奴はいい加減にしろ、
という話しでしかないけど、どこか変か？

>>547
Java の Generics ではできないの？
reflection 周りでそういう機能を実装してくれそうなヲカンがしてるんだが。

>>549
できない。VMもバイトコードも変更しない方針をとったから。
List<String>とList<Integer>には親子関係も兄弟関係もないただの別クラスになる。

>>549
仮に出来てもJava的にそういう手段は「用意しない」だろう。
Tの型がわかったところでテンプレートクラスの中で型情報を積極的に使ってしまうのは
あまりよろしくない。（型パラメータに制約をつけることはできる<T implements Comparable>とか）
方針として、
Java ・・・ 間違った使い方をされる恐れのあるものは極力排除する。
C# ・・・ 少しでも使えそうなもの、便利そうなものは全て取り込む。どのように使われるかについては関知しない。

というのがあると思う。
もちろんJavaが完璧とは言わないが、この思想はある程度成功していると思う。
（Genericsがこの思想に反しているとも思わない）

>>551
つまり、チミはList<Integer>とList<String>が何の関連もない状態がオブジェクト指向的に正しいと思ってるわけですね。

>>449-552
バイトコード上ではList<String>もList<Integer>も只のListになるんじゃなかったっけ？
ソースからバイトコードにコンパイルする時にGenericsは完全に解決されていて、
Generics関係の情報はSignature領域だけに残ると聞いてたんだけど。

>>553
>バイトコード上ではList<String>もList<Integer>も只のListになるんじゃなかったっけ？

そう。

学者じゃないから詳しいことはわからんが

>>552
>つまり、チミはList<Integer>とList<String>が何の関連もない状態がオブジェクト指向的に正しいと思ってるわけですね。

オブジェクト指向とGenerics（Template）は直行する概念では？

オブジェクト指向的に言えばIntegerListやStringListを作れって話になるんでしょ。
でもそんな同じようなのを大量に作るのは馬鹿みたいだから、Genericsが導入されるわけ。

>List<Integer>とList<String>が何の関連もない状態が
C#だろうがC++だろうが、IntegerList implements List, StringList implements List（←あくまでイメージね）
以上の関連があるようにも、必要にも思えないんだが。
何か俺の知らない素晴らしい機能でもあるのかね？

無知同士で言い合っても面白くないな。識者のコメント求む。

>>552,554
552>List<Integer>とList<String>が何の関連もない状態が〜
http://www-6.ibm.com/jp/developerworks/java/010608/j_j-genjava.html
日本語訳が間違っているので原文から持ってくると、
dW>The two assignments in Listing 10 are allowed
dW>---List 10---
dW>Vector rawVector;
dW>Vector<String> stringVector = new Vector<String>();
dW>rawVector = stringVector;
dW>stringVector = rawVector;
少なくともGJではVectorとVector<String>が*互いに*代入可能だそうだ。

メソッドの引数・パラメータやフィールドの型が違うのにそれはまずく無いか？

>>554
Genericsは厳密な型の継承ではなく特性の共有を可能にするわけだ。
List<Integer>とList<String>には今までのJava的な視点からは何の関連も無いが、
何かのコレクションであるという性質は共通してる。

C++のSTLなんかはシーケンスを表すだけでも複数の手段があって、
並べ替える際、要素を変更する際など、
そのコンテナの特性に合わせた最良の実装を提供するようになってる。

ある型がどんな性質を持っているのかを、せめてReflectionででも取得できるとうれしい。
が、Javaにそれが必要かというと、必要ないという結論が出たんだろうな。
なんにせよ、言語仕様としてまだ未熟。
ある型が何のテンプレートから作られたのかをよりスマートに記述できる方法が必要だな。
C#も、Reflectionに頼ってるようじゃ話にならない。

>>555
それ GJ っつー Java Generics の原型になった言語とコンパイラに関する記事みたいだけど。
それって Tiger で追加される Generics と全く同じなんか？

>>558
>それって Tiger で追加される Generics と全く同じなんか？
全く同じではない、というよりもGJを強化したものになるはず。
java.sun.comのEarly AccessのReview版（今取ってきた）では
public static void main(String[] args) {
LinkedList raw = new LinkedList<String>();
System.out.println(raw);
}
がコンパイル出来たので、Release版Tigerでも大丈夫なんじゃないかな。

>>559
っても
public static void main(String[] args) {
　LinkedList raw = new LinkedList<String>();
　raw.add( new Integer( 1 ) );
　System.out.println(raw);
}
とかすれば警告出るし。

public static void main(String[] args) {
　LinkedList raw = new LinkedList<String>();
　raw.add( "string" );
　System.out.println(raw);
}
でも警告出るんだよなぁ。
単純に
　LinkedList raw = new LinkedList<String>();
で警告出した方が簡単だと思うんだけど…

Java Generics の仕様良く知らんのだけど
　LinkedList raw = new LinkedList<String>();
ってのは警告もコンパイルエラーも出さないって仕様なの？
それともコンパイラがタコだから警告もエラーも出さないだけなの？

Java Generics の仕様って何処読めばいーんだ？

これかな。
http://www.jcp.org/aboutJava/communityprocess/review/jsr014/

>>562
ポインタさんきゅ。

spec8.pdf の 6ページ目 raw type から抜粋

For instance, it is possible to assign a Vector<String> to a Vector.
The reverse assignment from Vector to Vector<String> is unsafe from the standpoint of the generic semantics
(since the vector might have had a different element type),
but is still permitted in order to enable interfacing with legacy code.
In this case, a compiler will issue a warning message that the assignment is deprecated.

例えば、Vector<String> から Vector への代入は可能です。
逆に Vector から Vector<String> への代入は ginerics では(vectorは別の型の要素を持つ可能性があるので)危険ですが、
過去のコードとの連携を可能とするために、とりあえず許されています。
このケースではコンパイラは代入が deperecated であると警告を出すでしょう。

現段階の仕様でも stringVector = rawVector; は警告対象って事で。

変な糞仕様だな。(ﾌﾟ

http://homepage.mac.com/hiroyuki44/

>>547
そのために java.lang.reflect.Type ってゆー新しい interface が提供されるみたい。

> java.lang.reflect.Type
adding_generics-2_0-ea.zip には入ってないみたいだけどね。

>>560
警告がされている理由が違うような。下のコードでも同じ警告にならない？
public static void main(String[] args) {
LinkedList raw = new LinkedList();
raw.add("test");
}
つまり、「<>無しだとGenericsのチェックが入らないから警告。
雑多なものを詰めるつもりなら明示的に<Object>を指定しなさい」
という意味ではないかと。

>>568
うん、>>562 のリンク先を読んだときに見た。
でも この仕様だと generics 使わないコードとか
既存のコードをコンパイルしたときに警告出まくるよね。

これって警告がイヤな奴は全員 generics 使えって事なのか？
個人的には raw type の unchecked warning の部分は仕様変更にすべきだと思う。

っつか、 >>555 のリンク先にも

> GJではVectorとVector<String>が*互いに*代入

なんて事すれば警告出るって書いてあるんだけどね。
adding_generics-2_0-ea.zip は警告出さないみたいだけど。

このadding_generics-2_0-ea.zipだと
for (String s : ys)とか、printf(String fmt, Object[] args...)とか、
シンタックスシュガーが激増しているのはどうなのよ？
（VBみたいな意味での）簡単さの為にGenericsを導入するってのは嫌。
猿でなくてもソースを汚す。つうか、サンが汚してないか？

> 猿でなくてもソースを汚す。つうか、サンが汚してないか？
基本的には同意。

でも今更ジタバタしても遅いし。

>>571
sprintfは、java.text.MessageFormatに同じ機能あるよね？
どうしてか、このクラス普及しないんだよなあ…

Cのsprintfみたいなことがしたいのですが、どうしたらいいのでしょうか？
という質問が毎日のように発生する。

>>573
MessageFormat ってなんだかんだ言って不便だし。
基本的に空白で右詰できないとか、16進数を扱う NumberFormat が標準で用意されて無いとか。
空白で右詰は ChoiceFormat でやろうと思えばできない事は無いけど…

>>574
C++みたいにFormatカスケード出来ないからですか？
printfよりSTL互換を搭載して欲しい

>>575
> C++みたいにFormatカスケード出来ないからですか？
MessageFormat で
> > 基本的に空白で右詰できないとか、16進数を扱う NumberFormat が標準で用意されて無いとか。
が解消されれば必要ない。

> printfよりSTL互換を搭載して欲しい
例えばどんな？

>>548
遅レスだけど。

＞class MyCollection extends HashMap{
＞　public void putMyElement(int,MyElement);
＞　public MyElement getMyElement(int);
＞}
＞なんていう馬鹿なクラス切ってる奴はいい加減にしろ、
＞という話しでしかないけど、どこか変か？

要するに 上クラス中で、生の「get／put」が生で公開されている、と。
で、だからとりあえず「extends」は無いだろ！と、だからコンポジットしろ、と。

...つまりオレも「それは痛いな」と同意した、と。それだけ。

>>575
とりあえず、作ってみようか。君が。

http://homepage.mac.com/hiroyuki44/jaz09.html

>>573-575
何だか誤解をまねく発言をして申し訳ない。
このprintf(String fmt, Object[] args...)は
fmtの中の%にarg[#]を順番に代入していくだけのサンプルの関数なのよ。
で、私がムカついてたのは引数のObject[] args...という部分。
この...付きの配列で任意長の引数をとるんだと。
で、実際はこんな感じ。
呼び出し：printf( fmt, "first", new Integer(1) )
=>実際：　printf( fmt, new Object[]{ "first", new Integer(1) } )
・・・エディタでできることを言語仕様にいれてどうする。

extends 節がないと extends Object と書いてあるのと同じ扱いになる。
とか、
コンストラクタがないと、ClassName() { super(); } と書いてあるのと同じ扱いになる。
とかみたく、
ソースコードと実際に生成されるJVM用コードの間の差異を、脳内で補わなければならない
項目が増えますなぁ。

>>581
世の中にはそういう言語仕様上の枝葉のことばかり気にする、
他の言語をメインにしている馬鹿保守主義者が捨てるほどいて、
コッチから擦り寄らないと使ってもらえないんでしょうよ。

数人の天才が作る説得力を備えたルールは、大多数の馬鹿の政治的
思惑などによって汚され、エントロピーが増大していく。今も昔も
どこの世界でも同じだなあ。

>>576
そもそも MessageFormat って国際化のためのものだから、整形用(空白右詰/16進数表記)の
機能が無くてもいいと思うのだが。
// java.util.*Format で用意しろってのは分かるが。

>>575
> printfよりSTL互換を搭載して欲しい
JGL。

>>581
> extends 節がないと extends Object と書いてあるのと同じ扱いになる。
> コンストラクタがないと、ClassName() { super(); } と書いてあるのと同じ扱いになる。
どっちも許容範囲だと思うんだが…。

primitive をオブジェクトにするのと(boxing じゃなく)と operator overload が欲すぃ。

>>583
> そもそも MessageFormat って国際化のためのものだから、
なるほど。
でも昔は printf の代替として MessgaeFormat を宣伝してたような…

> primitive をオブジェクトにするのと(boxing じゃなく)と operator overload
それって C# ？

// あれ、名前消えた…なんでだ？

> でも昔は printf の代替として MessageFormat を宣伝してたような…
printf 相当の機能がない Java 厨が必死の対抗策として用意した反対意見だと俺は考える。
現に Javadoc には
> MessageFormat は、連結されたメッセージを、言語に依存しない方法で構築するためのものです。
としか書いてない。

> それって C#？
だねぇ。C# も何度か使ったけど、後追いだからそれなりに考えられてると思うよ。

>>585
>printf 相当の機能がない Java 厨が必死の対抗策として用意した反対意見だと俺は考える。
そそ。Sun のところにも在ったんだよね。
その宣伝に踊らされて頑張って Format 使ってた身としては
今更 Tiger では printf() が使えます、とか書いてあるの見ると複雑な心境…

Java厨が必死で否定してたC#の機能は全部Sunが認めて取り入れたわけだ。(嘲笑激藁

>>586
>その宣伝に踊らされて頑張って Format 使ってた身としては
ご愁傷様

すまん。
Formatと国際化はどう関係があるのかわからんのだが。

国際化用のAPIってResourceBundleだけちゃうの？

>Formatと国際化

メッセージを出す関数を考えてみよう。
関数の引数の順番は当然固定だ（仮に"S", "O", "V"だとする）。
特定の言語だけ、例えば日本語だけの場合は
そのままつないで「SがOをVしました」とすればいい。

で次にこの関数を英語に対応させようとした場合を考えてみよう。
引数に関係ない部分を英訳して日本語と同じようにつなげばいいじゃないかと
思うかもしれないが、「S Ved O」にならなければならない＝語順が違うので
引数の順序を変えないといけないというめんどくささがある。
逆にいうと引数の順序が変えられない場合は不自然な英訳になるか、
あるいはメッセージを出す関数を丸々作り変えないといけないことになる。

そこで固定部分は英訳するだけで済み、しかも引数の順序の変更にも対応している
Format が国際化では必要になるわけだ。

>>590
ようするにこういうことですな。
---
% make
make[1]: 入ります ディレクトリ
...
make[1]: 出ます ディレクトリ
---

>>591
おしい、Bundleに置いておくのはこれ

Enter directory {0}
Leave directory {0}

ディレクトリ{0}に移ります。
ディレクトリ{0}完了しました。

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

そーいや *.properties で
prop = ........ \
　..........

ってやると複数行にかけるって最近まで知らんかった。

閑話休題
autoboxing についてなんだけど unboxing conversion って何処で行われるのかわからん。

http://jcp.org/aboutJava/communityprocess/jsr/tiger/autoboxing.html
を読むと boxing conversion に関してはは assingment conversion(代入変換) とか
method invocation conversion(メソッド呼び出し変換) 時に行うって記述があるけど、
unboxing conversion の記述は無いんだよね。

> This proposal does not include the dual facility of auto-unboxing.
> However, the expert group may choose to contemplate that facility as well,
> if its inclusion can be done in a manner that is not overly disruptive to the language as a whole.
ってあるから、まだ auto-unboxing は無いんじゃないの？Casting conversion(キャスト変換)はあるから、
キャストで明示的に unboxing するしかないと。

>>596
なるほど。英語苦手なので そこ読み飛ばしてた。

ちなみに adding_generics-2_0-ea.zip だと casting conversion で unboxing されない…

gj.java:10: 変換できない型
検出値 : java.lang.Integer
期待値 : int
int i = (int)integer;

せめて今現在の仕様ぐらいちゃんと実装してくれ…

adding_generics-eaなんだからGenericsの早期実装じゃないのか？

early access なのに文句いってもしょうがあるまい。
1.5 が出て実装されてなかったらいうべきだが。

>>599
っつか、1.5 まで待ってたら仕様が fix されちゃうじゃんか。

unboxing の仕様が >>596 のような事なら、今なら意見言えば反映されるかも知らんのに。
そーゆー意味で、現在の仕様で良いのか議論するためにも early access 版だろーが
現時点の仕様ぐらい実装しておいてくれ(バグがあっても良いから) ってのはそんなに間違ってるのか？

.NETなんかはF#(OCaml)でgenericsサポートしてるわけだし。

2.2が出てまつよ。

2.0 だと variance ってのがあったらしいんだけど、2.2 だと使えない。

Integer[+] readOnlyIntegerArray = new Integer[10];
System.out.println(readOnlyIntegerArray[0]); //legal
readOnlyIntegerArray[0] = new Integer(0); //illegal

Integer[+] は読み込み専用配列、
Integer[-] で書き込み専用配列、
Integer[=] で読み書き両用配列らしい。
ちなみに Collection<+Number> とかやると読み込み専用セットとかになるらしーんだけど…
面倒くさいんで立ち消えになったのか？

autoboxing は未だにちゃんと実装されて無いよーです…
//boxing
Integer integer = (Integer)0; //キャスト変換、compile error
Integer integer = 0; //代入変換、compile error
new Vector.add(0); //メソッド呼び出し変換、ok
//unboxing
int i = (int)new Integer(0); //キャスト変換、compile error

あと enhanced for loop に使う java.lang.Iterable と
java.lang.SimpleIterator はあるんだけど(2.0 のときは在ったんだっけか？)
parameterized type を示す(らしい) java.lang.reflect.Type ってのはどーなったんだろ…

> new Vector.add(0); //メソッド呼び出し変換、ok
new Vector().add(0); //メソッド呼び出し変換、ok

保守

Javaらしくない仕様だな

>>607
「Javaらしい仕様」を400文字以内で説明せよ。

>>607
何が？

釣られるなよ。

>>603
CHANGESに書いてあるよ。不評だったみたいね･･･。

==========> jsr14_adding_generics-2_2-ea

変更は基本的にコンパイラのバグフィクスと安定化のみです。
先のリリース (2_1) は内部向けなので公開されていません。

現在のリリースは 1.4.2 を要求します。
1.4.1 でも動くかもしれませんが、サポートしません。

==========> jsr14_adding_generics-2_1-ea

variant な型パラメータを削除しました。反応を見るに、単に文法が拙かったのだと
考えています。 Tiger には variant のようなものは追加しません。代わりに、単に
正常でない配列を含む constructs(constructors(?)) を却下するようにしました。
その結果、variant についての文書を削除し、コンパイラから variant のサポートを
削りました。将来のリリースにおいて配列を generics とともに使用しやすくする
代替案を検討し続けます。

このバージョンでは以前のプロトタイプには無かった JSR14仕様の草案の機能の一つである
ワイルドカードおよび制限されたワイルドカードタイプパラメータをサポートします。
これにより、多くの generic メソッドのシグニチャがより簡潔に記述できます。
メソッド
　　<T extends E> void addAll(Collection<T> c);
は、「extends で制限されたワイルドカード」を使用して
　　void addAll(Collection<? extends E> c);
と書く事が出来ます。一方、メソッド
　　<U extends Comparable<U>, T extends U> void sort(List<T> l);
は 「super で制限されたワイルドカード」を使用して
　　<T extends Comparable<? super T>> void sort(List<T> l);
と書く事ができます。メソッド
　　<T> void shuffle(List<T> l);
は 「制限されないワイルドカード」を使用して
　　void shuffle(List<?> l);
と書く事が出来ます。

variance よりワイルドカードのほうが読みやすいだろうと思います。
ワイルドカードの文法は Neal Gafter, Gilad Bracha, Lars Bak, および Bob Deen によります。

varargs の文法は読みやすさを改善するためにわずかに変更されました。
新しい文法は James Gosling によります。
　　void printf(String fmt, Object... args);
このメソッドでは、変数 args は Object[]型です。

boxing および unboxing 変換は、現在 argument conversion としてのみ実装されています。
これはほとんど JSR 201 エキスパートグループが指定するものではありません。
プロトタイプは JSR 201 からより多くの指示を受けるまで更新されません。

こんだけ訳すのに1時間もかかってるよ…
途中で笑点見たりしてたけど…

>>615
おつ

（＾＾）

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン