5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【猿が】JavaニGenericsハ不要 【ソース汚す】

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

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

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

2 :デフォルトの名無しさん:03/06/14 00:53
2GET's


3 :デフォルトの名無しさん:03/06/14 00:58
関係無いけど、ジェネリックスのテンプレートって、キャストの解決
だけだっけ?

4 :デフォルトの名無しさん:03/06/14 01:12
まともにクラス設計してコード書いてるヤツなら、そもそもジェネリクスが
あった所で、そんなにソースは変わらないと思われ。


5 :無料動画直リン:03/06/14 01:13
http://homepage.mac.com/norika27/

6 :デフォルトの名無しさん:03/06/14 01:18
>>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/

7 :デフォルトの名無しさん:03/06/14 01:19
OOとジェネリクスは関係ない事をまず学べ

8 :デフォルトの名無しさん:03/06/14 01:22
糞野郎は何使わせても糞コードを書く罠

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

10 :1:03/06/14 01:25
あ、
> モデルの立場があいまいにならないか

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

11 :デフォルトの名無しさん:03/06/14 01:27
そもそも「要件は決まっているが型が明確に決まらない」部分を作る時に使うものじゃないの?


12 :デフォルトの名無しさん:03/06/14 01:27
うちではコレクションでのダウンキャスト避けにしか使わせない方向。

13 :デフォルトの名無しさん:03/06/14 01:32
enum は便利そうだけどね〜

14 :デフォルトの名無しさん:03/06/14 01:34
抽象概念から設計していくとすると、
逆に全部ジェネリック型な方が抽象っぽいような気がするけど・・・


15 :デフォルトの名無しさん:03/06/14 01:36
>>11
それって、開発途中の話でしょ。まさか最後まで型が明確に決まらないの?
しかもこれってUMLベースの話じゃないよ。
納品物をコンパイルするためのソースでっていう話だよ?


16 :デフォルトの名無しさん:03/06/14 01:38
>>14
開発途中ではある意味そうだと思うっていうか、そんな感じだろうけどさ。
開発終了までその状態ってどうよ。っていうか一度書いたらそのまま
行くでしょうよ。

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

17 :デフォルトの名無しさん:03/06/14 01:38
なんの関係もないオブジェクトを汎用的な処理に突っ込めるね

18 :デフォルトの名無しさん:03/06/14 01:41
コーディング規約レベルの話がIDEとかじゃなくて、コンパイラに含まれているっていうのは、
やっぱりSUN(とか)のマーケティングの賜物なんでしょうか。

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

19 :デフォルトの名無しさん:03/06/14 01:42
>>17
ある意味多態。ていうか無法。リフレクション機構が死にまくり伝説。

20 :デフォルトの名無しさん:03/06/14 01:42
汎用コンテナが安全に使えるのは単純にうれしい

21 :デフォルトの名無しさん:03/06/14 01:44
でも汎用コンテナが安全でなくなるケースっていうのが想像し難い。

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

22 :デフォルトの名無しさん:03/06/14 01:56
ここで分散オブジェクトの話持ち出して来たら、減点1。

23 :デフォルトの名無しさん:03/06/14 02:10
減点されるの承知で。

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

24 :デフォルトの名無しさん:03/06/14 02:15
JavaのGenericsが一体なんなのか分かってない奴が多数いる模様。

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

25 :デフォルトの名無しさん:03/06/14 02:18
>>23
「だってRMI経由でオブジェクトが来ると、何にキャストしていいかわかんなーい」
っていう旨の主張をしている人が過去に一人いたから。

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


26 :デフォルトの名無しさん:03/06/14 02:20
だってRMI経由でオブジェクトが来ると、何にキャストしていいかわかんなーい

27 :デフォルトの名無しさん:03/06/14 02:20
>>26
HashMapだろうが、ObjectInputStreamからインスタンス再生だろうが、
送り手(あるいは保存主)が何で、何をそこに突っ込んだかがわかってる時点(そんなの
仕様で決めてから開発するに決まってんだろって意味)で、
キャストなんて解決してるハズだろ

28 :デフォルトの名無しさん:03/06/14 02:23
>>24
だから、そのマクロ臭いプリコンパイルに頼って、クラス設計を適当にするヤツが
いて困るって話では。

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

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

何か違うと思わないか。

29 :デフォルトの名無しさん:03/06/14 02:24
>>26
二人目

30 :デフォルトの名無しさん:03/06/14 02:25
>>26-27
再現フィルム(協力・劇団ひまわり)

31 :デフォルトの名無しさん:03/06/14 02:25
>>25
> 「だってRMI経由でオブジェクトが来ると、何にキャストしていいかわかんなーい」
> っていう旨の主張をしている人が過去に一人いたから。
実際わかんないだろ。



32 :デフォルトの名無しさん:03/06/14 02:27
>>28
それスゲー痛い。(笑

33 :3アミーゴス:03/06/14 02:34
>>31
リフレクション(※1)を知らない様子。
ていうか、「実際わかんないし」ていう状態でRMIの受け手を開発しているっていうのは
いったいどういう案件なんだろうか。

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


34 :デフォルトの名無しさん:03/06/14 02:43
>>28
専門用語ばかりで何言っているのか分からないよ(T_T)

35 :デフォルトの名無しさん:03/06/14 02:50
漏れはあまりJava詳しくないからわからんのだけど、Genericsって、コレクション以外で
使う場所ってある?


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

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

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

37 :デフォルトの名無しさん:03/06/14 03:01
>>35
安直だけど、無いかも。そう考えるとますますいらないGenerics。

38 :デフォルトの名無しさん:03/06/14 03:11
http://www-6.ibm.com/jp/developerworks/java/030613/j_j-djc04093.html
>>35
君が想像しているよりはいろいろ出来るんだよ。

39 :デフォルトの名無しさん:03/06/14 03:16
話の流れとはジェンジェン関係無いけど、RMI(EJBでもいいや)で
キャストなんかいるのか?
Interface定義は(そこで使用されるValueObject定義も含めて)
サバ/クラ両方で予め交換しとくんじゃないの?

40 :デフォルトの名無しさん:03/06/14 03:27
>>38
これって考察文献だよね。(内容読んだ?)

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

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

41 :デフォルトの名無しさん:03/06/14 03:30
>>39
そういやそうだな。ていうかinterfaceの時点で "java.lang.Object" とか書かれてたら悪意を感じる罠。
スタブとか必要だしな。そういう意味でも事前にわかりまくり。

42 :デフォルトの名無しさん:03/06/14 03:34
>>40
もしかして、オブジェクト指向とAspectJとかの間に溝を感じたりする性質?
「対象全てを横断して等しく機能を織り込む」なんて、気持ち悪い?

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

43 :デフォルトの名無しさん:03/06/14 03:35
>>41
おそらくCORBAの話だったんだろうな。
CORBAのNARROWメソッドはアレだよな。

44 :デフォルトの名無しさん:03/06/14 03:38
アレじゃわからん

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

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

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

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

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

47 :デフォルトの名無しさん:03/06/14 04:17
>>46
バカは今まで公開インターフェイスでMap投げあったり(中に何はいってんだか
ぜんぶダイナミックにチェックしろってか?マジカヨ!)するようなことを平気でし
てたから(被害者同盟会員1でごじゃる)、それよりはいくらかましな状態になると
予想しているが。

48 :デフォルトの名無しさん:03/06/14 14:05
こんなクラスたまに見かける

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); // ← !
 }

}


49 :デフォルトの名無しさん:03/06/14 14:10
あとこんなのも

class Foo {

 private ArrayList list = new ArrayList();

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

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

}

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

50 :デフォルトの名無しさん:03/06/14 14:14
>>48-49
ご愁傷様

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

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

53 :デフォルトの名無しさん:03/06/14 14:58
それ解決させる為にテンプレート使うとか言う奴がいたら銃殺。

54 :デフォルトの名無しさん:03/06/14 15:13
時代はもうGenericsを無視できないからな
「機能をカプセル化する」だけしか考えられないのは時代遅れだろ。


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

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

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

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

56 :55:03/06/14 15:23
あ、>>1 の引用ね。

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


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


59 :デフォルトの名無しさん:03/06/14 15:41
Genericsでソースが汚れるんじゃなくて、ソース汚すヤツこそが単純に害。

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

61 :デフォルトの名無しさん:03/06/14 18:58
型総称性はかなり研究されているし、
強く型付けされた関数型言語(MLやHaskell)なんかでは
相当前から取り入れられていますが
その辺は無視ですか?>>57

62 :デフォルトの名無しさん:03/06/14 21:19
.NETなんかはF#(OCaml)でgenericsサポートしてるわけだし。

63 :デフォルトの名無しさん:03/06/14 23:37
とりあえず、>>1 の悩みには同意するのかしないのか。

64 :デフォルトの名無しさん:03/06/14 23:42
>>1
えー 俺はキャストが沢山あるほうが見にくいソースだと思うぞー

65 :デフォルトの名無しさん:03/06/15 00:01
これがわかってればOOわかってるみたいな基準ってありますか?

66 :デフォルトの名無しさん:03/06/15 00:09
とりあえず、考えるべきは
今のJAVAにGenericsを取り込むと何がいいのか?
でしょ。
メリットがあるなら、
デメリットが何であるかを理解しながら
使えば問題はない。

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

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

67 :デフォルトの名無しさん:03/06/15 00:12
>java.util.Collection系クラスの問題点
>
>要素取り出す際にはキャストが必要.
>意図しない型の要素も追加できてしまう.
http://objectclub.esm.co.jp/JavaGenerics/
からの引用だけど

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


68 :デフォルトの名無しさん:03/06/15 00:14
>>65
ポリモーフィズムとデザパタがわかってれば、
あとは経験だろ

69 :デフォルトの名無しさん:03/06/15 00:16
>>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();
}


70 :デフォルトの名無しさん:03/06/15 00:25
>>69
TypesafeEnumの自力実装って問題あるんだよ。知ってる?

71 :デフォルトの名無しさん:03/06/15 00:32
>>70
どんな問題ですか?
教えてください。

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


73 :マリー(C++派):03/06/15 00:54
演算子のオーバーロードをすればいいじゃない

74 :デフォルトの名無しさん:03/06/15 01:03
>>72
readResolveメソッドを適切に定義すればよいだけのこと。

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

75 :デフォルトの名無しさん:03/06/15 01:18
>>73,74
現状でも代替手段があるからいらないという意見もわかるが
言語側で面倒を受け持ってくれるならその方が便利でいいじゃん?

76 :デフォルトの名無しさん:03/06/15 01:25
使う場面なんかねーだろEnum

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

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

77 :デフォルトの名無しさん:03/06/15 01:29
>>76
本気で言ってますか?

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

79 :デフォルトの名無しさん:03/06/15 01:37
>>76
クソなのはお前の脳味噌だろ?

80 :74:03/06/15 01:55
>>75
> 現状でも代替手段があるからいらないという意見もわかるが
> 言語側で面倒を受け持ってくれるならその方が便利でいいじゃん?

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

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

81 :デフォルトの名無しさん:03/06/15 02:01
Javaのgenericsなんて糞。.NETみたいに関数型言語でエレガントに実装しろよ馬鹿。

82 :デフォルトの名無しさん:03/06/15 02:06
リフレクション上 List<String> と List<Integer> に何の関連もないなんて何て糞な実装だ。(ワラ

83 :デフォルトの名無しさん:03/06/15 02:17
だってJavaだもん

84 :デフォルトの名無しさん:03/06/15 02:17
>>73
> 演算子のオーバーロードをすればいいじゃない
そういう汚染系機能はいらんな。equals()メソッドをオーバライド
する規約にしたほうが開発者同士の混乱を最小限に抑えることができる。


85 :デフォルトの名無しさん:03/06/15 02:19
>>81
そもそもC#にはGenericsなんてないもん。
よってC#はもっと糞

86 :デフォルトの名無しさん:03/06/15 02:24
>>85
あるよ。

87 :デフォルトの名無しさん:03/06/15 02:32
>>86
Yukonとかいったらぶっ殺す

88 :デフォルトの名無しさん:03/06/15 03:05
Javaって演算子オーバーロードないのに、どうして
Stringにだけは+が使えるの?

89 :デフォルトの名無しさん:03/06/15 03:15
文字列は基本型に近いから String も特別扱いされてる。
(他の言語では文字列型が int や double と同列に扱われているものもある)

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

90 :デフォルトの名無しさん:03/06/15 04:44
>>88
ぶっちゃけ、設計者の独断。

91 :デフォルトの名無しさん:03/06/15 04:50
>>89
近いだけなの?基本型じゃないの?

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


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

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



93 :デフォルトの名無しさん:03/06/15 17:17
>>92
> 文字列は同じだがオブジェクトは異なるといったことができなくなる。

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

94 :デフォルトの名無しさん:03/06/15 17:51
>>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

をご覧ください。


95 :デフォルトの名無しさん:03/06/15 18:57
>>92
>> + は print()文使用時に役に立つ。が、StringBuffer#append()より遅い。

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

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



96 :デフォルトの名無しさん:03/06/15 19:47
>>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");

になるから速い。(嘘

97 :デフォルトの名無しさん:03/06/15 21:55
>>96
ネタついでに、"A"+"B"+"C"は、コンパイル時に
"ABC"に置換されるから、物凄い速いよ。

98 :デフォルトの名無しさん:03/06/15 22:03
>>97
それは言語仕様ですか?それともSunのコンパイラが
そう評価するという話ですか?

99 :デフォルトの名無しさん:03/06/15 22:15
http://www.y-adagio.com/public/standards/tr_javalang/15.doc.htm#39990
>>98
仕様ではないようですな。
んでもって、Sunのコンパイラはそうしてますな。

100 :94:03/06/15 22:44

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

101 :デフォルトの名無しさん:03/06/15 22:51
>>100
変数は使いまわしたほうが速いよ!ホントだよ!

102 :デフォルトの名無しさん:03/06/15 23:31
で、Genericsは必要ってことでいいよね。 キャスト無い方が見やすいし。

103 :デフォルトの名無しさん:03/06/15 23:48
Genericsのメリット
キャストが減ってウマー

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

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

104 :デフォルトの名無しさん:03/06/16 09:29
イヤーンなのは、ソースが綺麗だの汚いだのいっている奴に限って、やたらアクの強いめちゃくちゃ汚いソースを書くって所かね。
たとえは 1 見たいな事を言うような奴とかね。
設計設計言っている奴にろくな設計をする奴がいないんだよな。

105 :デフォルトの名無しさん:03/06/16 17:56
C#がGenerics実装すんの待ってこけるかどうか見極めてから実装すりゃいいじゃん。
正直JavaやC#でGenericsを使っても、キャストが減って便利、以上の収穫は得られないと思う。

106 :デフォルトの名無しさん:03/06/16 21:35
>>105
その収穫で十分じゃん。Generics欲しい。

107 :デフォルトの名無しさん:03/06/16 23:19
>>105
.NETのGenericsはこけようがない。
元々は関数型言語のPolymorphismをC#でも利用できるようにしただけだから。

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

108 :デフォルトの名無しさん:03/06/17 01:09
単なるコンパイル時点でのプリコンパイルもどきで、バイナリ互換は
保たれるなら、便利なシンタックスシュガーだと思えばいいだけちゃうの?
こけるってなにがどうこけるんですか?

109 :デフォルトの名無しさん:03/06/17 01:13
よく仕組みをしらないけど、コレクラスファイルのサイズ増えたりしないの?

110 :デフォルトの名無しさん:03/06/17 01:15
>>109
コンパイル時に型チェックするという作業が、コンパイラに増える
だけらしい。

111 :デフォルトの名無しさん:03/06/17 01:46
>>107
こけるといっても言語はOSと違うもんだ。C#や.NETはJavaほどにWindowsに依
存しやすいようにはなっていない。多くのOSに対応しOSに対する依存性が少ない分
こけても生き残る。

112 :デフォルトの名無しさん:03/06/17 01:50
日本語変だな

113 :デフォルトの名無しさん:03/06/17 01:54
>>111
こっちは素面だが、なに言ってるかわからん。

114 :デフォルトの名無しさん:03/06/17 02:26
【猿が】Java厨ニハCommunicationSkillガ必要【デスマーチ踊る】

115 :デフォルトの名無しさん:03/06/17 03:22
>>111の翻訳に挑戦しました

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

あれ?

116 :デフォルトの名無しさん:03/06/17 03:33
言語仕様をシンプルに保つっていうのはJavaのいいところだと思ってたけど違うの?
Generics云々よりも、関心のあるところはこういう技術"外"の話なんだけど。

117 :デフォルトの名無しさん:03/06/17 03:52
>>116
同意
こうやってどんどん仕様が肥大化していっていつかC++の二の舞になりかねないぞ

118 :デフォルトの名無しさん:03/06/17 06:02
Genericsごときでこれほど大騒ぎしているうちは大丈夫

119 :デフォルトの名無しさん:03/06/17 07:35
Java は冗長なところが貫かれていて一貫性あったけど、
こんな具合にやられるとなー。中途半端だ。

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

120 :デフォルトの名無しさん:03/06/19 00:40
中途半端だし、やっぱ無駄。

121 :デフォルトの名無しさん:03/06/19 00:43
つーか無くていい。
コレクションがなんでも入って困るというなら、それを利用する側(イメージとしては、あるクラスが内部に値を保持する為に
privateにコンポジットしたコンテナだとか思いねェ)が、ゲッタ/セッタで制御すればいいっつーか、
そういう風に普通しねぇか?


122 :デフォルトの名無しさん:03/06/19 00:48
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);
 }
}

これって普通だよな。

123 :デフォルトの名無しさん:03/06/19 00:58
> public Data get() {
>   return (Data)list.get();
> }
コンパイルエラー

124 :デフォルトの名無しさん:03/06/19 01:06
>>122
いちいちそう書かなくていいようにあるんだろ

125 :デフォルトの名無しさん:03/06/19 01:11
get と add程度 しかメソッドが必要ないならそれでもいいかもしれないが
ホントにリストとして使いたいときに
List インタフェースの豊富な便利なメソッドが使えないのはイタイ。

126 :デフォルトの名無しさん:03/06/19 01:14
>>122
そういうのを自動生成してくれるツールないの?

127 :デフォルトの名無しさん:03/06/19 01:24
>>125
メソッド一つあたり3行追加すれば良いだけだし。
(Iterator返すメソッドとかを除いて)

128 :デフォルトの名無しさん:03/06/19 02:06
>>126
どうせ自動生成に頼るのだったら
Generics導入してもいいと思うが。

129 :デフォルトの名無しさん:03/06/19 05:56
結論。

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

130 :デフォルトの名無しさん:03/06/19 06:11
>>128
いや、Genericsが使えない(サポートする予定が当面ない)コンパイラでも使えるので便利かなぁと思ったんですが

131 :デフォルトの名無しさん:03/06/19 06:31
>>129

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

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

--

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

132 :デフォルトの名無しさん:03/06/19 06:36
>>131
組織の能力はメンバの能力の最大公約に制限されるからな

133 :デフォルトの名無しさん:03/06/19 08:17
package 2ch.tech;
public class Aori extends Res {
pulic static void main(String [] args) {
System.out.println(">>131 馬鹿とか言うなー。");
}
}

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

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

135 :121-122:03/06/19 08:48
自己レス・補足
> コレクション系やリスト系はたいてい裸のまま外に出さないで、
> それを包含するクラスの方が外に出る

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

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

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

136 :デフォルトの名無しさん:03/06/19 08:52
言語仕様なんて単純な方がいい。凝るのは中身だ。

137 :デフォルトの名無しさん:03/06/19 08:53
Genericsはより「全体の中でどんなクラスを書き、配置するべきか」を考えるために無駄を省いてくれると思う。

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

138 :デフォルトの名無しさん:03/06/19 08:58
今うちの会社ではまだ開発の中でGenericsの話って具体的に出てきて無いけど、
他のメンバの中に危険な発言をする者がいる。

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

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

139 :121-122:03/06/19 09:00
>>137
すまん。例が悪かった。あれは、単なるラッパの例として出したかった訳じゃない。
( >>134 参照)

140 :デフォルトの名無しさん:03/06/19 09:11
>>138
そいつマジで言ってたら猿以下だ・・・

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

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

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

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

142 :デフォルトの名無しさん:03/06/19 09:27
DataList 作るよりは、Data[] を返すメソッドを定義してそれを活用するようにしたほうがいい。

143 :デフォルトの名無しさん:03/06/19 09:35
>>134

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

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

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

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

144 :デフォルトの名無しさん:03/06/19 21:40
タイプ量減らしたいだけなら、Cかなんかのプリコンパイラでも使え。
Velocityとかのテンプレートエンジンでもいいぞ。


145 :デフォルトの名無しさん:03/06/20 00:29
えーと、プロパティが欲しいってこと?

146 :デフォルトの名無しさん:03/06/20 00:53
publicフィールドを書いたらエラーになって、
get、setを自動で作ってくれる、
プロパティと同じ働きをするものを
冗長なコードとして出力してくれる機能がほしい。

147 :デフォルトの名無しさん:03/06/20 00:54
>>146
IDE使えばたいていついてるだろ。

148 :デフォルトの名無しさん:03/06/20 01:18
IDE使うとプロジェクト依存になりそうで嫌なんですよ。

149 :デフォルトの名無しさん:03/06/20 01:21
正直、その程度の機能ならちょろっと自作できるだろ

150 :デフォルトの名無しさん:03/06/20 01:31
Javaにもプロパティがあったらよかったのにな。
どうせ、プライベートメンバなんて
setter、getter経由でしかアクセスしないのだから。

151 :デフォルトの名無しさん:03/06/20 01:34
とおもった人がC#の開発陣にいたよというお話でした

152 :デフォルトの名無しさん:03/06/20 01:38
>>150
確かに、obj.propと言う風に使うとして、
propがパブリックメンバにも、
プライベートメンバにも変更可能なのは
利点だと思う。

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

153 :デフォルトの名無しさん:03/06/20 01:39
Rubyおもいっきしset/getでしょ。


154 :152:03/06/20 01:40
> プライベートメンバにも変更可能なのは
なんかおかしかったな。修正↓

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

155 :デフォルトの名無しさん:03/06/20 01:52
俺は名前空間が無い言語でXXX_とかいうプリフィックスをつけて区別していた。
名前で意味を変えるという手段はもうやめてほしい。

156 :デフォルトの名無しさん:03/06/20 01:57
>>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 と書くのはなんか気持ち悪い気がする。

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

157 :デフォルトの名無しさん:03/06/20 01:59
>>156
あんたプロパティの意味わかって言ってる?

158 :デフォルトの名無しさん:03/06/20 02:00
>>156
その利点・欠点をあなたがまず語ってください
話はそれからだ

159 :デフォルトの名無しさん:03/06/20 02:04
>>156
間違っているよ。修正しといてあげる。

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


160 :デフォルトの名無しさん:03/06/20 02:05
プロパティが無くてもタイプ量は5文字程度しか変わらないんだけどね。
その差もIDEとかの入力支援があれば殆ど気にならんし。

161 :デフォルトの名無しさん:03/06/20 02:05
Java厨の認識・知識はその程度のもん。
語るに落ちる

162 :デフォルトの名無しさん:03/06/20 02:07
>>160
正確には使用している個所×5文字ですね。

163 :デフォルトの名無しさん:03/06/20 02:09
Genericsが無くてもちょっとタイプ量が増えるだけ。
そういうことを繰り返すからタイプ量が膨大に増えるわけですね。

164 :デフォルトの名無しさん:03/06/20 02:09
カッコが面倒

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

166 :デフォルトの名無しさん:03/06/20 02:13
タイプ量増えるって言ってる人々ってIDEの入力支援使ってないの?

167 :デフォルトの名無しさん:03/06/20 02:20
プロパティの場合
単純なgetter setterではない時に、可読性が落ちる位だけど。

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

168 :デフォルトの名無しさん:03/06/20 03:42
スレ違いかもしれんが
プロパティあるとgetterメソッドにしようか、読取専用プロパティにしようか迷うね

169 :デフォルトの名無しさん:03/06/20 04:43
ごめんにょ、Javaに戻る気がしない。


170 :デフォルトの名無しさん:03/06/20 04:57
obj.info.name = "hoge"
   ↑実はinfoのクローンが返っているので、この代入は無効

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

171 :デフォルトの名無しさん:03/06/20 06:56
>>170
それは
obj.getInfo().setName("hoge");
と書く場合でも起こりえることだと思うが。

172 :デフォルトの名無しさん:03/06/20 07:08
>>171
起こりえるけど警戒度が違うと思u

173 :デフォルトの名無しさん:03/06/20 07:27
>>165
誰だよ、そんなことあるわけないだろ。

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

174 :デフォルトの名無しさん:03/06/20 10:15
>>168


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

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


175 :デフォルトの名無しさん:03/06/20 10:39
Eiffelの、公開データメンバでも外からの代入は不可、はいい妥協点だと思ったり。

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

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

177 :デフォルトの名無しさん:03/06/20 16:49
>>161
>Java厨の認識・知識はその程度のもん。
>語るに落ちる

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

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



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

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

179 :デフォルトの名無しさん:03/06/20 17:05
C#ではset/getが使えただけで果たしてJavaより本当に使いやすくなったのか
という議論はどこかのスレでもすでに散々議論されていたと思うのだが。

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

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

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







180 :デフォルトの名無しさん:03/06/20 17:38
まあC#はこれからも好きなだけ色んな便利機能追加して、結局cに似たVBになるんでしょうから

181 :デフォルトの名無しさん:03/06/20 17:39
>>179
長々と書いてくれたんだが、喩えが的を射ていないのが残念だ。

182 :デフォルトの名無しさん:03/06/20 18:25
> プロパティなのかインスタンス変数のpublicなフィールドなのか一目で区別しにくい。
厳密にはpublicフィールドは存在しません。
すべてプロパティ扱いです。
publicフィールドはなし。すべてsetter、getterでアクセスしろよりましでしょ。

183 :デフォルトの名無しさん:03/06/20 18:26
>>180
そういうJavaもあれほど不要だと言ってきた機能が追加されつつあるけどな。

184 :デフォルトの名無しさん:03/06/20 18:37
enum はずっと欲しいと思ってたよ。

185 :デフォルトの名無しさん:03/06/20 21:06
>>183
だれが何を不要といったものかね?
ゴスリングが不要といったものが追加されたとでも?
あれは「C#にもあったものは不要といわれていたものが追加された」
のではなく「C#にあったものとは似て非なるものが追加された」というのじゃよ。

186 :デフォルトの名無しさん:03/06/21 00:54
いつのまにかプロパティの話に

187 :デフォルトの名無しさん:03/06/21 00:55
>>185
言葉遊び。恥ずかしい。

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

189 :Java厨のひとりですが:03/06/21 01:32
>>188
あんな馬鹿といっしょにしないでくれ…

190 :デフォルトの名無しさん:03/06/21 02:16
>>188
メタデータとしてメソッド/フィールド/プロパティを区別することが
なぜ重要なんですか?

191 :デフォルトの名無しさん:03/06/21 02:20
>>190
処理の意味が明確になる

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

193 :デフォルトの名無しさん:03/06/21 02:30
>>191
・メソッドとプロパティを区別する意味
・フィールドとプロパティを区別する意味
についてもう少し詳しく教えてください

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

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

こんなところかな。

195 :デフォルトの名無しさん:03/06/21 02:57
>>194
区別する意味が一つも書いてないよ。

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

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

196 :デフォルトの名無しさん:03/06/21 03:02
>>188
一口にメタデータといっても無数にあり、君の思っているようなメタデータは
どのプログラマも想像するようなメタデータとは異なるわけだ。

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

197 :デフォルトの名無しさん:03/06/21 03:07
フィールドとの対比はかいてあるじゃん
ある言語に依存した事もかいてあって偏ってるけど

198 :デフォルトの名無しさん:03/06/21 03:08
>>194
そのC#独自仕様のプロパティを使った場合のデザインパターンやアーキテクチャパターンの
サンプルソースを見せれ。

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

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

200 :デフォルトの名無しさん:03/06/21 03:11
>>194
それを見ているとプロパティのオーバーライドはプロパティでしか使えないようにしか見えない。



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

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


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

202 :直リン:03/06/21 03:13
http://homepage.mac.com/yuuka20/

203 :デフォルトの名無しさん:03/06/21 03:14
>>194
>  プロパティは概念的に属性というものを表現するときに使い、それが実際のデータに対応いている必要は無い。
>  これもバージョン間の互換性を高める。

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

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

204 :デフォルトの名無しさん:03/06/21 03:15
>>201
Javaとは関係ない話題はC#スレに誘導してやれ。

205 :デフォルトの名無しさん:03/06/21 03:18
>>203
UMLではでしょ。
property:財産、資産、特性、属性

206 :デフォルトの名無しさん:03/06/21 03:18
>>203
俺はJava屋でMSの概念はよくわからんが、どうやら昔からフィールド
とよんでいるものを、2つ以上の役割に分割したいらしいね。

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

207 :デフォルトの名無しさん:03/06/21 03:18
「C#のプロパティ」って動脈(メソッド)と静脈(フィールド)が混ざり合った両生類の
心臓のようなキモイものみたいだな。

208 :デフォルトの名無しさん:03/06/21 03:19
C#厨が珍しくメンバ関数のことをメソッド、メンバ変数のことをフィールドと言ってる。

209 :デフォルトの名無しさん:03/06/21 03:21
>>205
> >>203
> UMLではでしょ。
> property:財産、資産、特性、属性

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

210 :デフォルトの名無しさん:03/06/21 03:24
俺は必死な>>201のC#のプロパティの説明が、
「C言語にはポインタ、関数ポインタが使えJavaよりも柔軟性が高いので
JavaよりC言語の方が便利ですよ」
といっているようにしか聞こえないのだが。


211 :デフォルトの名無しさん:03/06/21 03:24


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

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

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

213 :デフォルトの名無しさん:03/06/21 03:26
両陣営で言葉の定義が違うのになにやってんだおまえらは

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

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

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

215 :デフォルトの名無しさん:03/06/21 03:32
>>213
少なくともM$の言葉の定義やネーミングセンスは技術者の視点からみると
独善的で政治的で最悪。

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

216 :デフォルトの名無しさん:03/06/21 03:34
単にOOPの一般的な仕様に対する、特定用途用のサブセットでしかない
存在を自慢げに語っている馬鹿がいる、という理解でいいのかな?
Javaなら、JavaBeansをコンポジットしたクラス作れば終わりだな。

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

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

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

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

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

220 :デフォルトの名無しさん:03/06/21 03:46
しかしJavaプログラマは言語仕様に関しては保守的な意見が多いな
使わなければいいだけの話なのに

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


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


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

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

223 :デフォルトの名無しさん:03/06/21 04:07
なんでC#とJavaの話になってるんだよ。
Genericsはどうでもいいのか?

224 :デフォルトの名無しさん:03/06/21 07:21
昔ボーランドが Javaにプロパティを入れてくれと頼んだがやっぱり断わられたそうだ。
同じような理由からだったと思う。beansにもシリアライズで対応出来るからとか、

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

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

225 :デフォルトの名無しさん:03/06/21 13:28
メタデータで区別できる → リフレクションで区別できる だろ。
Javaでどうやるんだよ?

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

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


226 :デフォルトの名無しさん:03/06/21 13:38
ネーミングルールを利用して運用でカバーするのが
Javaのやり方です。プリフィックスって知らない?

227 :デフォルトの名無しさん:03/06/21 13:39
アホアンチがデルパイのプロパティまで否定したのか。(ゲラ

228 :デフォルトの名無しさん:03/06/21 13:42
スーパー
 スーパー
スーパー
   スーパー
スーパーハンガリアーン


   スーパーハンガリアーン

229 :デフォルトの名無しさん:03/06/21 13:44
メソッドのシグネチャを見れば分かるならいいじゃん。
Java が出来たのは 1995 年だということをお忘れなく。

230 :デフォルトの名無しさん:03/06/21 13:49
JSTLのelを知ったとき、「やっぱJavaにもプロパティあった方がいいのか」と
思ったのは俺だけですか?
elでは、$hoo.bar と書くとfoo.getBar()と同じ意味になる。
値をセットする文脈で使えばfoo.setBar(buz)になる。

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

231 :デフォルトの名無しさん:03/06/21 13:54
>>228
ハンガリアンがいただけないのは、
オブジェクトの役割ではなく型に基づいて命名している点と、
守らなくても動作するのでしばしば規則を破られる点。

232 :デフォルトの名無しさん:03/06/21 13:55
Javaのgenerics仕様は糞。
将来.NETの仕様をパクる羽目になるよ。

233 :デフォルトの名無しさん:03/06/21 13:57
>>230
Generic は Java に導入されるので、
C++ や Effiel や C# のそれとの違いを調べてない人は、
プロパティのように 「プロパティもないのか」 と単純な煽りができない。
よって話題にできる人が限られている。

234 :デフォルトの名無しさん:03/06/21 13:57
>>228
Javaのプロパティがいただけないのは、
メソッドの役割ではなく名前の形に基づいて命名している点と、
守らなくても動作するのでしばしば規則を破られる点。

235 :デフォルトの名無しさん:03/06/21 13:57
ありゃ。
s/Effiel/Eiffel/

236 :デフォルトの名無しさん:03/06/21 13:59
>>233
Javaのgenericsは、それがgenericsから作られたことをクラス名でしか判断できない。
リフレクションでは判別できない糞仕様。

237 :デフォルトの名無しさん:03/06/21 14:00
>>236
つまりはset〜、get〜のプロパティと同じ。

238 :デフォルトの名無しさん:03/06/21 14:02
>>234
> メソッドの役割ではなく名前の形に基づいて命名している点と、
わからん。
ってゆーと理解できない奴がバカとか言われんだろうなぁ。

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

239 :デフォルトの名無しさん:03/06/21 14:03
煽りにマジレスするなよ

240 :デフォルトの名無しさん:03/06/21 14:11
>>236
genericsは名前に<>があることで判別できる。
プロパティもget/setで判別できる。

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

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

241 :デフォルトの名無しさん:03/06/21 14:22
>>234
Java にプロパティはないけど。JavaBeans にはあるが。
あとシグネチャ規約を破ると(原則的には)プロパティと認識されない。

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

242 :デフォルトの名無しさん:03/06/21 14:46
プロパティーが必要な理由と、
genericsがリフレクションで区別されるべき理由を教えて欲しいんだけど・・・

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

厨房でごめんなさい。

243 :デフォルトの名無しさん:03/06/21 14:57
口で言って判るようなメリットはさ、単なる売り口上でさ、 実際はメリットじゃない事が多いんだよ。


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


244 :デフォルトの名無しさん:03/06/21 14:58
ただし生兵法は怪我の元で、ちょっと齧ってダメとかいうのは止めてね。

245 :デフォルトの名無しさん:03/06/21 14:59
つまりVB.NETこそ体験すべき言語と

246 :デフォルトの名無しさん:03/06/21 15:05
> 口で言って判るようなメリットはさ、単なる売り口上でさ、 実際はメリットじゃない事が多いんだよ。
簡単に言うと、説明できないって事ですか

247 :デフォルトの名無しさん:03/06/21 15:09
>>245
Delphiでもいいです。

248 :デフォルトの名無しさん:03/06/21 15:12
>>242
gotoがあればcontinueもbreakもいらない。
足し算があれば掛け算はいらない。
必要ないものを消していったらほとんどのものはいらない。
厨房にはまだ分からんかも知れんが。

249 :242:03/06/21 15:12
違いのよくわかるソースコードjava版とDelphi版をあげて
もらえるとわかるかもしれないのですが・・・

250 :デフォルトの名無しさん:03/06/21 15:14
>>248
それは「必要な理由」になって無いな

251 :デフォルトの名無しさん:03/06/21 15:15
>>248
Java には goto 無いよ。予約語のリストの中には入ってるけど。

252 :デフォルトの名無しさん:03/06/21 15:15
>>249
for(i=0; i<10; i++) {
if(i == 5) break;
}

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

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

253 :デフォルトの名無しさん:03/06/21 15:15
>>250
ためしにbreakが必要な理由を教えてくれ

254 :デフォルトの名無しさん:03/06/21 15:17
>>253
質問に質問で返すのはルール違反だよ。

255 :デフォルトの名無しさん:03/06/21 15:21
>>252
求められてるのは break と goto の違いでなくてプロパティの有無でしょ。

256 :デフォルトの名無しさん:03/06/21 15:21
>>254
質問じゃなくて、相手を考えさせようとする手段。
コーチングでは一般的な手法。

257 :デフォルトの名無しさん:03/06/21 15:22
まぁ厨房はなんでそうなっているのかもう少し考えろってこった。

258 :デフォルトの名無しさん:03/06/21 15:26
>>256
いや、プロパティが無いからJavaは糞って言う連中がいたので
プロパティが有ると何が良いのか知りたいんだけど。

259 :デフォルトの名無しさん:03/06/21 15:27
>>258
言葉づかいがすっきりとなる。

260 :デフォルトの名無しさん:03/06/21 15:27
>>258
そういうくだらない煽りは無視してください

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

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

262 :デフォルトの名無しさん:03/06/21 15:30
Genericsもプロパティと同じでいらんよ。
ためしに両方で書き比べても対して利点は無い。

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

264 :デフォルトの名無しさん:03/06/21 15:39
>>263
>だけどbreakが無くて全部gotoで済ましちゃう言語は、Javistからみたら糞だろ?
別に?

265 :デフォルトの名無しさん:03/06/21 15:42
gotoの欠点も知らんのか・・・。

266 :デフォルトの名無しさん:03/06/21 15:52
>>263
goto には詳しいらしいけどプロパティには詳しくないのか?

267 :デフォルトの名無しさん:03/06/21 15:54
ごめん、genericsあると糞コードが出来るって、たとえばどんなの?
もうオヤジなのでコレクションのキャストが要らなくなるウマー、くらいしか想像できんのだが.

268 :デフォルトの名無しさん:03/06/21 15:56
厨房の次はオヤジか。

269 :デフォルトの名無しさん:03/06/21 15:56
皆さんがんがって議論してますね〜

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

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

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




270 :デフォルトの名無しさん:03/06/21 15:58
>>266
プロパティはオブジェクトの特性の設定・取得を明確に出来る。

271 :242:03/06/21 16:11
C#のプロパティはあってもなくてもあまりかわりませんよね。


272 :デフォルトの名無しさん:03/06/21 16:12
認識できない奴にはいくら言っても無理か。

273 :デフォルトの名無しさん:03/06/21 16:15
結局、JAVAでsetter/getterするのに対するメリットをいえてないからね。

274 :デフォルトの名無しさん:03/06/21 16:17
goto厨にbreakのメリットがわからないのと一緒だな

275 :デフォルトの名無しさん:03/06/21 16:22
C#のプロパティはsetとgetでアクセシビリティを変えられないので糞。

276 :デフォルトの名無しさん:03/06/21 16:25
後藤はどこにでも飛ぶから、訳わからないうどんが出来る。breakはブロック抜けるだけに限定されてそれをふせげる。
setter/getterはなんでも出来るから訳がわからない○○○ができる(?)。プロパティはXXXXXだけに限定されてそれをふせげる。

埋めてくれよ、天才。


277 :デフォルトの名無しさん:03/06/21 16:29
高速化/単純化するために制御構文で決められた以外の場所に飛びたければ goto が必要。
XXXXしたければ プロパティが必要。
でも良いよ。

278 :デフォルトの名無しさん:03/06/21 16:31
JAVAで高速化のためにgoto?
ネタですよね?

279 :デフォルトの名無しさん:03/06/21 16:33
>>277 の一行目は二行目のサンプルだよ。
そもそも Java に goto が無いのは知ってるけど。
誰かさんが goto と break に拘るので。

280 :デフォルトの名無しさん:03/06/21 16:41
プロパティのメリットまだあ?

281 :デフォルトの名無しさん:03/06/21 16:45
何かを強制したり、その機能でなければ実現できないことがなければメリットが無いってわけじゃないだろ?
俺としては>>270は十分なメリットだと思うよ。
別にこれをメリットと思わなくてもかまわないと思うけど、263のように、それを説くだけ時間の無駄。

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

282 :デフォルトの名無しさん:03/06/21 16:54
何が出来るとかいう訳じゃなく、区別するといいね、かっちり区別を強制できるわけじゃないけど、
つうことね。それならなっとく。
つまり _言語の機能_ としてはまったく未熟ということでFA?FA。

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

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

284 :デフォルトの名無しさん:03/06/21 17:04
で、genericsで出来る糞コードってどんなのよ.

285 :デフォルトの名無しさん:03/06/21 17:13
>>225
> メソッドの頭に「get、set」がついてたらプロパティだなんて糞アホな仕様だと思わない?
> メソッドの頭に「test」がついてたらunit test用メソッドだなんてみっともないと思わない?

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

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

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



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

286 :デフォルトの名無しさん:03/06/21 17:14
Javaにはdelegateがないからgenericsもまともに活用できない

287 :デフォルトの名無しさん:03/06/21 17:16
>>286
delegateがあるとどんなメリットがある?

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


289 :デフォルトの名無しさん:03/06/21 17:17
>>285
おいおい、あまり暴走するな。
J2SE1.5の仕様を予習しとけ。

290 :デフォルトの名無しさん:03/06/21 17:17
>>286
お前ははコレクションをつかうのにわざわざdelegateを使うのか。

291 :デフォルトの名無しさん:03/06/21 17:18
>>285
いずれもC#の仕様ではなくてCLIの仕様だとだけ言っておこう。

292 :デフォルトの名無しさん:03/06/21 17:19
>>290
プ。generics = Coolectionか。
こりゃまた物知らずが現れたな。

293 :デフォルトの名無しさん:03/06/21 17:23
285
> ソースコードのメソッドなどの手前に [TestFixture]や[STAThread]をつけるなんて
つけなくてもいいよ。
でもつけないで作ったらどうなると思うかな?

294 :デフォルトの名無しさん:03/06/21 17:25
つーか、genericsを活用したいなら関数型言語でもやっておけ。
所詮はParametric PolymorphismがJava/C#でも使えます、ってだけだから。

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

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

296 :デフォルトの名無しさん:03/06/21 17:26
>>294
Lispをやってどうする?

297 :デフォルトの名無しさん:03/06/21 17:27
> Genericsのメリットの一つはコレクション系の操作が楽になることだろ。

うははは。すげー馬鹿。

298 :デフォルトの名無しさん:03/06/21 17:28
>>293
> 285
> > ソースコードのメソッドなどの手前に [TestFixture]や[STAThread]をつけるなんて
> つけなくてもいいよ。
> でもつけないで作ったらどうなると思うかな?

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

299 :デフォルトの名無しさん:03/06/21 17:29
>>297
煽り厨は氏ね

300 :デフォルトの名無しさん:03/06/21 17:29
>>295
Function as Objectを実現できない

301 :デフォルトの名無しさん:03/06/21 17:29
煽りも叩きもどうでもいいから
マジでdelegateを使ったGenericsの活用法を知りたい。

302 :デフォルトの名無しさん:03/06/21 17:30
なんでこのスレにC#厨やVB厨が邪魔しているんだ?

303 :デフォルトの名無しさん:03/06/21 17:30
>>300
"as" という文字列がいかにもVB厨臭くて失笑。

304 :デフォルトの名無しさん:03/06/21 17:36
これだから教養の無い奴は(苦笑

305 :デフォルトの名無しさん:03/06/21 17:37
Java厨はFunction as Objectなんて知らないのだから。

306 :デフォルトの名無しさん:03/06/21 17:37
>>295
関数オブジェクト がgenericsでどう活躍するのか説明キボン。

307 :デフォルトの名無しさん:03/06/21 17:41
そして、OO概念であるintrfaceではダメな理由も.

308 :デフォルトの名無しさん:03/06/21 17:42
さらに無知ぶりを発揮。


309 :デフォルトの名無しさん:03/06/21 17:46
知ったか君が入って荒れてきたな。
説明できないんだったら消えてイイよ.
この世から。

310 :デフォルトの名無しさん:03/06/21 17:56
お前らが煽るからほんとに消えちゃっただろ。
ぜひ説明してほしかったのに。

311 :デフォルトの名無しさん:03/06/21 18:05
無理無理.どうせ知ったか君は説明なんて出来ないよ。
煽りだけの知ったか君は消えてよし。その存在自体が。

312 :デフォルトの名無しさん:03/06/21 18:11
http://pc2.2ch.net/test/read.cgi/tech/1054523453/79

313 :デフォルトの名無しさん:03/06/21 18:12
ところでJavaだとコレクション以外にGenericsの使い道が無いように思うがどうよ。

314 :デフォルトの名無しさん:03/06/21 18:26
>>313
>>1 曰く邪悪なことが出来るそうだが…。おれはどういうのなのか浮かばん。

315 :デフォルトの名無しさん:03/06/21 18:38
>>301
F#そのものがそのサンプル

316 :デフォルトの名無しさん:03/06/21 18:41
Delphiの場合は高速コンパイルを維持したままRAD-IDEとのコンビネーションがとても旨くハマッタけどJAVAだとどうかな

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

317 :デフォルトの名無しさん:03/06/21 18:43
> Delphiの場合は高速コンパイルを維持したままRAD-IDEとのコンビネーションがとても旨くハマッタけど
てきとーな事言って誤魔化しているな。

318 :デフォルトの名無しさん:03/06/21 18:48
確かに意味不明

319 :デフォルトの名無しさん:03/06/21 18:55
意味判んない?
  Delphiは published + property を使ってる。
  pubished というのは実行時型情報を 持ちなさいという指令だ。

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

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

320 :デフォルトの名無しさん:03/06/21 19:30
>>319
>>316がそういう意味だと言うつもりかね。プププ

321 :デフォルトの名無しさん:03/06/21 19:31
Delphiなインターネットはここですか?

322 :デフォルトの名無しさん:03/06/21 22:40
結局.NET使いに言い負けてしまったか

323 :デフォルトの名無しさん:03/06/21 22:58
>もしGet/Set式だと イベント呼び出しの負荷は倍になってた訳で、
0.0000000001秒くらいだけど。
コンパイラで最適化できるけど。

324 :デフォルトの名無しさん:03/06/21 23:00
>この情報を使って IDE は 簡単にプロパティエディタを表示出来たわけだ。
Javaもできるけど・・・

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




325 :デフォルトの名無しさん:03/06/21 23:01
>Function as Object
Interfaceに対するメリットをどうぞ

326 :デフォルトの名無しさん:03/06/21 23:11
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;
  }


327 :デフォルトの名無しさん:03/06/21 23:11

  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);
    }
  }
}

328 :デフォルトの名無しさん:03/06/21 23:13
念のため実行結果。

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

329 :デフォルトの名無しさん:03/06/21 23:28
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が返ってきたりするようなのを
ポリモしないんで。
そうなってるなら、設計がクソで
すなわち破綻を意味する。

330 :デフォルトの名無しさん:03/06/21 23:30
あ、ちなみにT0,T1,T2
の代替になる物があるかと言われれば
instance of
というのがあるからね。
まあ、普通は使わない。


331 :デフォルトの名無しさん:03/06/21 23:44
>>329
意図が分かってもらえなかったかな?
引数・戻り値の型が色々変わった時にどうするという話。
引数も戻り値もint固定なら、わざわざgenerics使うアフォはいないわけで。

332 :デフォルトの名無しさん:03/06/21 23:58
C#でそのサンプルは無理があるんでねーの?
F#はコンパイル時に型推論に基づいて適切なFuncion<>型を作るわけだから。
プログラマが自分からFuncion<>型を作ることはしないし。

333 :デフォルトの名無しさん:03/06/21 23:58
delegateがないと、なんでこれができないんだ????
genericsだけ在れば良いんじゃね−の?

334 :デフォルトの名無しさん:03/06/22 00:02
>>333
delegateも所詮は型なんだからその通りだと思う。
C#はシンタクスシュガーでメソッドをオブジェクトのように扱ってる「気になれる」だけ。
こういうのね。

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

335 :デフォルトの名無しさん:03/06/22 00:05
closureもどきを作るならdelegateの方が楽なのもまた事実。

336 :デフォルトの名無しさん:03/06/22 00:10
.NET 2.0ならこんなことも出来るし。

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

337 :デフォルトの名無しさん:03/06/22 00:27
で、Genericsのせいで、厨が書いて困るようなコードってどんなのよ? >>1

338 :デフォルトの名無しさん:03/06/22 00:35
ここはJAVAスレじゃないのか?
ドトネト厨のオナーニはまだ終わってないのか?

339 :デフォルトの名無しさん:03/06/22 00:46


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


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

340 :デフォルトの名無しさん:03/06/22 00:50
Java厨はgenericsを使ってないようだ。
.NET使いの方が上。

341 :デフォルトの名無しさん:03/06/22 01:25
>>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; }


342 :デフォルトの名無しさん:03/06/22 01:25

 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;
 }



343 :デフォルトの名無しさん:03/06/22 01:25
 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のポリモーフィズムってどうやってんの?(w

344 :デフォルトの名無しさん:03/06/22 01:31
ソースの行数は圧倒的にC#の方が少ないな。

345 :デフォルトの名無しさん:03/06/22 01:33
>>344
あたりまえでしょ(w

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

346 :デフォルトの名無しさん:03/06/22 01:33
どうでもいいがJava陣営はgenerics使いたがらないな。(w

347 :デフォルトの名無しさん:03/06/22 01:35
>>345
あたりまえでしょ(w

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

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

    foreach (Delegate d in func) {
ここと

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

348 :デフォルトの名無しさん:03/06/22 01:36
>>346

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

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

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

349 :デフォルトの名無しさん:03/06/22 01:40
ところでJavaのgenericsってメソッドのみでの型パラメータは使えるの?

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

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

350 :デフォルトの名無しさん:03/06/22 01:41
>>344
記憶しなきゃならないルールはJavaの方が少ないな。(ハゲワラプ

351 :デフォルトの名無しさん:03/06/22 01:42
>>349

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

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

352 :デフォルトの名無しさん:03/06/22 01:43
ちなみにC#では>>349はOK。

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

353 :デフォルトの名無しさん:03/06/22 01:47
Javaのgenericsは中途半端で使えないことが明らかになったようだ。
C#の方が柔軟で強力で、generics対応のソースも公開されてるし。

354 :デフォルトの名無しさん:03/06/22 01:47
>>352

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


来るんじゃねえ
ターコw

355 :デフォルトの名無しさん:03/06/22 01:48
.NET2.0 > SSCLI + gyro >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> J2SE1.5

356 :デフォルトの名無しさん:03/06/22 01:50
>>355

Win95でも動けばな

357 :デフォルトの名無しさん:03/06/22 01:50
やっぱり.NETの方がエレガントだね。
Javaは破綻してる。

358 :デフォルトの名無しさん:03/06/22 01:52
J2SE1.5

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

359 :デフォルトの名無しさん:03/06/22 01:53
>>357

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


360 :デフォルトの名無しさん:03/06/22 01:54
そしてVB.NETに3年遅れて今さら出てくるProject Rave

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


362 :デフォルトの名無しさん:03/06/22 01:54
>>358
それはC#になれたユーザを囲い込みたいだけなので、プログラムの本質とは離れると思うが

363 :デフォルトの名無しさん:03/06/22 01:55
Javaってほんと糞だな。

364 :デフォルトの名無しさん:03/06/22 01:56
>>363

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

思想自体たこなんだな

365 :デフォルトの名無しさん:03/06/22 01:57
>プロパティのない糞仕様
>使えないgenerics
>C#の後追いながらも中途半端で劣るforeach、enum、metadata、auto-boxing
キャストを無くすgenerics以外は特に欲しい機能ないな・・・





366 :デフォルトの名無しさん:03/06/22 01:57
>>363
糞だからMSに徹底的に修正されて出来たのが.NET。
悪いけどJavaはもう一度ゼロから作り直さないと.NETには勝てないよ。

367 :デフォルトの名無しさん:03/06/22 01:58
>>366

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

368 :デフォルトの名無しさん:03/06/22 02:00
J#でswingが使えるんだって。
http://msdn.microsoft.com/vjsharp/supui/
SWTも使えるし、もうJavaやる理由なんてないよ。

369 :デフォルトの名無しさん:03/06/22 02:00
とりあえず、

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

370 :デフォルトの名無しさん:03/06/22 02:00
>>358
正しくは、他言語ほどには使えなくした Generics なんだけどね。
Java は馬鹿のための道具と言いたければ言いねえ。
それでもプロジェクトは進めなきゃならん。

371 :_:03/06/22 02:01
http://homepage.mac.com/hiroyuki44/

372 :デフォルトの名無しさん:03/06/22 02:01
Java使って書いたコードが
J#でも使えるの?
だったら、JAVAで書いて
気が向いたらJ#でコンパイルしてあげてもいいかな。

373 :Micro$oftシャイーン:03/06/22 02:03

今 日 も 沢 山 釣 れ た な

 禿藁プ

374 :Oracleシャイーン:03/06/22 02:08
CLIってSIG-SEGV出るんでしょ?

禿藁プ

375 :デフォルトの名無しさん:03/06/22 02:09
>>358
enum は Java の方がいろいろ機能があるね。
http://jcp.org/aboutJava/communityprocess/jsr/tiger/enum.html

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

376 :デフォルトの名無しさん:03/06/22 02:10
今のJavaはかつてのVBを見てるような気分だ。
付け焼き刃状態でどんどん機能追加してるが根本を変えないと駄目な状態。

377 :Sunシャイーン:03/06/22 02:12
今年からマイクロソフトを見習って宣伝部員の雇用拡大。

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

禿藁プ

378 :デフォルトの名無しさん:03/06/22 02:12
>>376
まあ、否定はできない

379 :デフォルトの名無しさん:03/06/22 02:13
>精神学者


380 :デフォルトの名無しさん:03/06/22 02:14
まぁ、

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

ClassクラスにReflection出来たり、

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

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

381 :デフォルトの名無しさん:03/06/22 02:15
>>379

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

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

382 :デフォルトの名無しさん:03/06/22 02:16
でもintはObject派生してない糞仕様

383 :デフォルトの名無しさん:03/06/22 02:18
心理学とか神経学じゃなくて精神学なの?
聞いたこと無いけど。

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

384 :デフォルトの名無しさん:03/06/22 02:18
C#も同じでしょ?
Boxing、Unboxingなんていう、頭ゆるくする機能があるだけ。

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

385 :Sunシャイーン:03/06/22 02:19
>>383
アメリカ人は勝ち負けにこだわるので適当に造語しただけ、

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


386 :ちよ:03/06/22 02:19
おねがいしま〜す♪
http://www1.free-city.net/home/kotarou/page003.html

387 :デフォルトの名無しさん:03/06/22 02:20
>>385
ちなみに英語でのスペルは?

388 :Sunシャイーン:03/06/22 02:23
学問的にはともかくとしてだな、、、


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

389 :Sunシャイーン:03/06/22 02:23
mental; spiritual; moral.

390 :デフォルトの名無しさん:03/06/22 02:24
仕事ではもはや単価廉くてC#なんて冒険やってられないだけどね。

391 :デフォルトの名無しさん:03/06/22 02:24
>>384
メタクラスを持っていながらもObjectに代入できないのか。
C#では可能なのに。

Object o = 0;

392 :デフォルトの名無しさん:03/06/22 02:24
>>389
精神じゃなくて「精神学」のスペルだよ。

393 :デフォルトの名無しさん:03/06/22 02:25
プロパティを採用しない理由を考えてみた。

JakartaのBeanUtilだと、

alice.bob.carol

これは、

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

プロパティいらね



394 :Sunシャイーン:03/06/22 02:26
「精神観察」に格下げしておくよ

395 :デフォルトの名無しさん:03/06/22 02:27
>>372
J2SE1.4以降のみにあるクラスライブラリで書いたコードすべてがJ#で使えるとは思えないが。
RMMIもJ2EEのクラスも使えないんだったら必要性感じない。

396 :デフォルトの名無しさん:03/06/22 02:28
>>391

ふーん。

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

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

397 :デフォルトの名無しさん:03/06/22 02:28
>>376
そいつはC#ではないかと。VB厨がC#厨になんとかすばやく昇格できるようにと

398 :デフォルトの名無しさん:03/06/22 02:30
クラスといったオブジェクト指向、そしてデザインパターンだけでできるものを
foreach,set/get,delegateといい
わざわざ言語のシンタックスとして追加したC#は失敗だな。プ

399 :デフォルトの名無しさん:03/06/22 02:30
>>394
「精神観察」ってググっても7件しかヒットしないぞ。

400 :デフォルトの名無しさん:03/06/22 02:31
>>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());
}


401 :デフォルトの名無しさん:03/06/22 02:31
>>390
C#の案件もJavaの6分の1くらいだし

402 :デフォルトの名無しさん:03/06/22 02:31
>>396
コンパイルエラー。

403 :Sunシャイーン:03/06/22 02:32
>>399
そうそう、そういう意味で使った

404 :Sunシャイーン:03/06/22 02:32
>>402
馬鹿じゃねーの(プ

405 :デフォルトの名無しさん:03/06/22 02:34
C#のプロパティもdellegateも落ちこぼれVB厨を救うために作られた糞仕様
最初から使用禁止にしておけばもっとエンタープライズ規模なプログラミングを効率よくできたものを。

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

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

      ..釣れたよ〜・・・│
      ────y──┘
 
       ・゚・。 ○ノノ。・゚・
    ~~~~~~~~~~│~~~~~~~~~~~~~~~
           ト>゚++< ミ パクッ
     ジタバタ  ハ
         ノ ノ


407 :デフォルトの名無しさん:03/06/22 02:35
>>400
C#にIntegerだのSystemクラスはありません。

408 :Hewletシャイーン:03/06/22 02:36
>>407
書き直せよ

409 :デフォルトの名無しさん:03/06/22 02:36
C#だとintはObjectだな

410 :デフォルトの名無しさん:03/06/22 02:37
>>403
で、「精神観察」のスペルは?

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

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

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

412 :デフォルトの名無しさん:03/06/22 02:40
http://honyakuinfoseek.infoseek.co.jp/amitext/indexUTF8.jsp

によるとMoral observation
らしい。

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

413 :デフォルトの名無しさん:03/06/22 02:40
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) {
      java.lang.System.@out.println(i + " : " + target[i].GetType());
    }
  }
}

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

414 :デフォルトの名無しさん:03/06/22 02:40
>>334
> Function<int, int> f = new Function<int, int>(SomeFunc);
> int result = f(100); // ←これね
ソースコードを反って読みにくくしているだけじゃないかと。
C#厨の大好きなスパゲティコードは消えてくれ。

415 :デフォルトの名無しさん:03/06/22 02:42
>>413
なんでそれで、

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

A + B + C が計算できないわけ(?_?;)

416 :デフォルトの名無しさん:03/06/22 02:42
>>414
スパゲティコードの意味が違うような。
むしろ>>334は短くなってるわけだし。

417 :デフォルトの名無しさん:03/06/22 02:43
>>415
Object型に+演算子定義がないから。

418 :デフォルトの名無しさん:03/06/22 02:45
>>417
所詮付け焼刃

419 :デフォルトの名無しさん:03/06/22 02:45
>>415
error CS0019: 演算子 '+' を 'object' と 'object'
型のオペランドに適用することはできません。

420 :デフォルトの名無しさん:03/06/22 02:46
これならOK。

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

421 :デフォルトの名無しさん:03/06/22 02:47
なんだか、C#は後だしじゃんけんに勝ったつもりでいるようだけど
Javaにとって反面教師になっているみたいだね。

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

422 :デフォルトの名無しさん:03/06/22 02:48
>>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にしてすっきりさせろ。

423 :デフォルトの名無しさん:03/06/22 02:48
>>413
なんかだましてないか?

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

IConvertible インターフェイス

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

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

424 :デフォルトの名無しさん:03/06/22 02:49
>>422
いいところに気付いたね。
genericsでSystem.Voidは使えないのだよ。
だからnullをunit代わりにしてる。

425 :デフォルトの名無しさん:03/06/22 02:50
>>423
もうひとつ追加ね。

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

426 :デフォルトの名無しさん:03/06/22 02:51
>>417
> >>415
> Object型に+演算子定義がないから。

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

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


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



427 :デフォルトの名無しさん:03/06/22 02:56
>>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

428 :Sunシャイーン:03/06/22 02:56

 今 日 も 沢 山 釣 れ た な 

                                         禿藁プ

429 :Micro$oftシャイーン:03/06/22 02:59
>>427

墓穴を掘ってしまった
蛸宣伝シャイン

430 :デフォルトの名無しさん:03/06/22 02:59
>>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()

431 :デフォルトの名無しさん:03/06/22 03:00
ようするに、

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

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



432 :デフォルトの名無しさん:03/06/22 03:01
>>430

Javaでイイや。(藁

433 :デフォルトの名無しさん:03/06/22 03:03
>>1
genericsよりもC#にあるdelegate, set/getがJavaにそっくりそのまま移植されたら
VB厨のようなスパゲティ厨房が増えて困ってしまうな。

434 :デフォルトの名無しさん:03/06/22 03:03
純粋なOOで逝くか、Genericで逝くか、それが問題だ!

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

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

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

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

435 :431:03/06/22 03:05
訂正訂正、

やるなら↓かなぁ?

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


436 :デフォルトの名無しさん:03/06/22 03:05
>>431
なに? 演算子のオーバローディングできない?

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


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

437 :デフォルトの名無しさん:03/06/22 03:05
>>431
継承できるメソッドだよ。

438 :デフォルトの名無しさん:03/06/22 03:06
>>434
コーディング基準を決めるときはどうするんだyo!

439 :431:03/06/22 03:06
>>434
そういう話はわかりきった事なので、あえてここでは取り上げてない。

来るんじゃねー
ターコw

440 :431:03/06/22 03:07
>>436

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

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


441 :デフォルトの名無しさん:03/06/22 03:08
>>434
いやまて、Genericsなしでは、
コレクションを使うときわざわざinstanceofを使う羽目になることがある。

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

442 :デフォルトの名無しさん:03/06/22 03:08
というか、
SmallTalkをチョッパヤにするVM欲しくなったぞ。

443 :デフォルトの名無しさん:03/06/22 03:10
>>440
誤差の丸め方法まで作っているのか?
あれなしで多倍長高階関数を作るのは面倒くさい。


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

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

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



445 :デフォルトの名無しさん:03/06/22 03:11
>>443
誤差?

そんなのあった?

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

446 :デフォルトの名無しさん:03/06/22 03:13
アラン・ケイ氏,大いに語る

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

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

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

ケイ:.NETのほうが,Javaよりはいい。

藤枝:本当に?。

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

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

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

447 :439:03/06/22 03:13
>>444

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

448 :_:03/06/22 03:15
http://homepage.mac.com/hiroyuki44/

449 :デフォルトの名無しさん:03/06/22 03:15
Windowsでしか動かない事に非常に恐怖します。

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

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

450 :434,444:03/06/22 03:16
アヒャ。
自己レスになってるー(汗

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


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

てなわけで、もう来ねぇよ。ウワーン。


451 :デフォルトの名無しさん:03/06/22 03:21
このスレ見てるとJavaのgenericsじゃなくてC#のを覚えてしまいそうだ。

452 :デフォルトの名無しさん:03/06/22 03:22
>>449
DelphiとC#は同じでもJavaはちがう。

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

453 :デフォルトの名無しさん:03/06/22 03:23
>>452
引き抜かれたのは、某Javaエンジニアだよ。間違えない

454 :デフォルトの名無しさん:03/06/22 03:23
>>449
> Delphi,Java,C#、作った人間同じなんだけどね。
某から引き抜かれた Anders Hejlsberg じゃないっすよね。
誰だろ?

455 :デフォルトの名無しさん:03/06/22 03:24
>>445
BigDecimal#divide(BidDecimal 割られる方, int 小数点以下の桁数, int 丸めモード)

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


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

456 :デフォルトの名無しさん:03/06/22 03:25
>>453
藻前はヘジルスがJavaエンジニアだとでもいいたいんちゃうか?

457 :デフォルトの名無しさん:03/06/22 03:27
ヘジルスがJavaを全く知らなかったらC#なんてJava似の言語は作れなかっただろう。
そんでJavaに熟知したヘジルスのことをJavaエンジニアとも比喩してるってことか。

458 :デフォルトの名無しさん:03/06/22 03:27
>>455
比較するときの話だと思ったよ。
double a, b, c;

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

459 :デフォルトの名無しさん:03/06/22 03:27
某Javaエンジニア = 某ランドのJavaエンジニア = ヘジルスバグ
なるほど

460 :デフォルトの名無しさん:03/06/22 03:28
>>457
畜生!!
開き直ってやる。
間違えてましたー。

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

461 :デフォルトの名無しさん:03/06/22 03:28
hage

462 :デフォルトの名無しさん:03/06/22 03:29
> Delphi,Java,C#、作った人間同じなんだけどね。
ってのはどーなったんだ?

463 :デフォルトの名無しさん:03/06/22 03:30
>>458
機械エプシロンはそんな使い方するよりもっと効率のよい方法がある。

464 :デフォルトの名無しさん:03/06/22 03:31
>>460
> だけどBorlandにもJavaエンジニアは居ますー。BlackDownパクリましたー。
そりゃJBuilderが会社の存亡を握っているような会社だからねえ。

465 :デフォルトの名無しさん:03/06/22 03:32
>>462
間違えなのかー。
.NETが出た当時、ZDNETに掲載されていた
 気 が す る 。

466 :Sunシャイーン:03/06/22 03:35
 モ マ イ ラ

 と こ ろ で 

 G e n e r i c s は 

 ど う よ 。


467 :デフォルトの名無しさん:03/06/22 03:37
機械エプシロン


/*
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倍するの?

468 :デフォルトの名無しさん:03/06/22 03:38
>>466
instanceofを使いたくないときのためだけに使う。
それ以外では使用禁止。

469 :デフォルトの名無しさん:03/06/22 03:41
>>467
どこからかソースこぴったなw
EXIT_SUCESSとかいてるあたりが奥村の「C言語による・・・」にクリソツだなw

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

470 :デフォルトの名無しさん:03/06/22 03:44
>>469

入社試験の問題でさ、

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

らしいのよ

471 :デフォルトの名無しさん:03/06/22 03:46
>>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=
一番上のとこからコピペしたみたいですね。

472 :デフォルトの名無しさん:03/06/22 03:48
>>470
ソートして小さい奴から足すってのじゃなくて?

473 :デフォルトの名無しさん:03/06/22 03:50
しかしみなさん、博学ですな

474 :デフォルトの名無しさん:03/06/22 03:51
>>472
その日本語だと失敗だな。
ソート関数書いてみそ。
これ以上このネタは禁止ネ

475 :デフォルトの名無しさん:03/06/22 03:52
>>472
正数と負数はわけよう

476 :デフォルトの名無しさん:03/06/22 03:54
あ、絶対値って入れなきゃダメって事か。

477 :デフォルトの名無しさん:03/06/22 04:07
Genericsはどこいった???

478 :デフォルトの名無しさん:03/06/22 05:12
>>470
Pack10進法に変換して足す。

479 :デフォルトの名無しさん:03/06/22 08:32
>>472
 じゃあ、ほぼ同じ値が沢山並んでる場合はどうなる?

480 :デフォルトの名無しさん:03/06/22 09:19
>>472
 じゃあ、ほぼ同じ値が沢村並んでる場合はどうなる?


481 :デフォルトの名無しさん:03/06/22 12:45
genericsとOOは混在できないって話の前提をみんな無視しすぎでしょう。
genericsでできる事はOOでもできる。
従って、OOをベースに
genericsをコレクションにのみ適用するのは
すごく賢いやり方だと思うんだけど、どう?

482 :デフォルトの名無しさん:03/06/22 12:51
>>481
>genericsとOOは混在できないって話の前提をみんな無視しすぎでしょう。

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

483 :デフォルトの名無しさん:03/06/22 13:35
>>481
猿が、板汚す

484 :デフォルトの名無しさん:03/06/22 14:11
>>481
直交する概念だから混在できるって前提だろ……

485 :デフォルトの名無しさん:03/06/22 14:21
C++でOOとgenericsを混在させると
えらい事になるのは事実だね。


486 :デフォルトの名無しさん:03/06/22 14:41
それはC++におけるOOもgenericsも
Cに増改築した結果取り入れられたものだから。

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

487 :デフォルトの名無しさん:03/06/22 20:59
ん?
って事は、結局
Java+Genericsは最強って事か。

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

489 :デフォルトの名無しさん:03/06/23 02:31
>このスレを読む限りJavaしかやってない奴は型パラメータを判ってない奴が多いと
おまえがOOをわかってないだけなんじゃない?
instance of って知ってる?
ポリモーフィズムって知ってる?

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


490 :デフォルトの名無しさん:03/06/23 02:36
OOとGenericsは関係ないとあれほど



491 :デフォルトの名無しさん:03/06/23 06:04
>489はバカ

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

(´゚c_,゚` ) プッ

492 :デフォルトの名無しさん:03/06/23 06:25
instanceofを使う奴は白痴

493 :デフォルトの名無しさん:03/06/23 09:37
いまさらだけど、、
>>1の文章読みづらい

494 :デフォルトの名無しさん:03/06/23 23:49
スレストあげ

495 :デフォルトの名無しさん:03/06/24 00:12
instance of なんて
型でif文書いてるようなもんだしなぁ。意味なし

496 :デフォルトの名無しさん:03/06/24 06:27
せっかくポリモフィズムやってるのに型ごとに条件分岐なんてしてたらおいしさ半分だと思われ。

497 :デフォルトの名無しさん:03/06/24 08:00
型パラメーターってのは全部instance ofで置き換えられるけど、
ポリモフィズムを使うのが普通だね。

498 :デフォルトの名無しさん:03/06/24 08:03
型がObjectにまでに成り下がったのなら
もうポリモフィズムも糞もないだろう

499 :デフォルトの名無しさん:03/06/24 08:07
Object厨もVariant厨も同じようなもんですね(w

500 :_:03/06/24 08:13
http://homepage.mac.com/hiroyuki44/

501 :デフォルトの名無しさん:03/06/24 08:48
JSPのカスタムタグで、ネストされたタグの中からその親タグを判別する時、
その親タグが「何のタグかわからない」ので、結局instanceOfでしか判別できない罠。
ていうかコレって、別にパラメータの話じゃなかったね。

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

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

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

503 :デフォルトの名無しさん:03/06/24 09:15
--
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

--

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

504 :_:03/06/24 09:42
http://homepage.mac.com/hiroyuki44/

505 :_:03/06/24 12:14
http://homepage.mac.com/hiroyuki44/

506 :デフォルトの名無しさん:03/06/24 12:26
>>503
1.5倍のどこが安いのかと。

507 :デフォルトの名無しさん:03/06/24 13:10
>>506
ただ同然じゃん

508 :デフォルトの名無しさん:03/06/24 13:20
>型がObjectにまでに成り下がったのなら
>もうポリモフィズムも糞もないだろう
普通はinterfaceを使うだろ。

509 :_:03/06/24 13:41
http://homepage.mac.com/hiroyuki44/

510 :_:03/06/24 15:07
http://homepage.mac.com/hiroyuki44/

511 :_:03/06/24 16:53
http://homepage.mac.com/hiroyuki44/

512 :_:03/06/24 18:21
http://homepage.mac.com/hiroyuki44/

513 :デフォルトの名無しさん:03/06/24 23:36
>>instanceof
Java とは関係ないが CLOS (Common Lisp Object System) だと
型ごとに条件分岐するのが正しいやり方だ。

514 :デフォルトの名無しさん:03/06/25 03:55
>>489に加勢

>>491はバカ
> (´゚c_,゚` ) プッ (藁



515 :デフォルトの名無しさん:03/06/25 08:20
514==489
> (´゚c_,゚` ) プッ (藁

516 :デフォルトの名無しさん:03/06/25 14:25
>>515
はずれ。顔文字が餓鬼っぽいプ

517 :デフォルトの名無しさん:03/06/25 21:46
ほしゅ


518 :デフォルトの名無しさん:03/06/28 20:54
不要という結論で良いのか?

519 :デフォルトの名無しさん:03/06/28 20:55


520 :デフォルトの名無しさん:03/06/29 12:18
Javaにはプ呂派手ィも印出腐も出理下ー斗も不要。

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

521 :デフォルトの名無しさん:03/06/29 13:47
>>520
お前のソースは汚そうだな

522 :デフォルトの名無しさん:03/06/30 00:29
でかいシステムでフレームワークモドキ作ってるオナニー連中が喜びそうだな。
今ですらハッシュテーブルとベクターで汎用バケツ作ってアプリを大混乱に陥れてるというのに。

523 :デフォルトの名無しさん:03/06/30 00:49
>>522
>今ですらハッシュテーブルとベクターで汎用バケツ作って
そこにちゃんと型を明示できるようになるからいいんですよ

524 :デフォルトの名無しさん:03/06/30 02:27
>523
残念ながらそのハッシュテーブルには文字列が入ったり文字列配列が入ったり Bean が入ったり Exception が入ったり...

525 :デフォルトの名無しさん:03/06/30 17:40
>>524
しかしint等は入らない。これがVariantとの違いであり、素晴らしいことだ。

526 :デフォルトの名無しさん:03/06/30 17:56
Generics 要らんから、primitive 型もオブジェクトにしてくれ。

527 :デフォルトの名無しさん:03/06/30 19:23
Autoboxingっていう機能がprimitive型とラッパークラスの変換してくれるんじゃなかったっけ。

528 :デフォルトの名無しさん:03/06/30 20:28
なぜそこまでしてVariant化したいのかわからん。

529 :デフォルトの名無しさん:03/07/01 02:06
コレクションの機能を使って何かを纏めてしまっておく時、普通のヤツは
何か意味のある集合をまとめてしまっておくはずだーな。
そういう「あるクラスの機能を利用する」関係の場合は、コンポジション
が基本だよな。

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

530 :デフォルトの名無しさん:03/07/01 21:45
>>529

うにゃ、

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

531 :デフォルトの名無しさん:03/07/01 21:45


532 :デフォルトの名無しさん:03/07/01 21:57
つまりGenericsは必要、とl。

533 :デフォルトの名無しさん:03/07/01 22:31
Windows版の最新JAVAは
http://java.sun.com/webapps/download/Redirect/52201172/27014527-220/j2re-1_4_2-windows-i586.exe
でダウンロードできるよ

JAVAが早くなるよ。みんなインストールしよう!


534 :デフォルトの名無しさん:03/07/01 22:37
>>529
あー、もち、getAsStringとかgetAsNumberとか無いならゴミだね。それ

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

535 :デフォルトの名無しさん:03/07/01 23:08
↑ゴミ

536 :デフォルトの名無しさん:03/07/01 23:12
なんでもObjectに突っ込むアホを防ぐための機能と思ってたが

537 :デフォルトの名無しさん:03/07/01 23:43
>>536
なんでも突っ込めるようにObjectにするための機能でしょ。

538 :デフォルトの名無しさん:03/07/02 21:56
なんでもアホに突っ込むObjectを防ぐための機能だろう。

539 :デフォルトの名無しさん:03/07/02 22:39
Objectがアホになんでも突っ込むのを防ぐための機能じゃないの?

540 :デフォルトの名無しさん:03/07/04 00:04
>>530 >>534
コレクションに直接プリミティブとして扱われる値を入れてインターフェイスにして
いるとしたら、そっちのほうが問題だな。

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

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

とかじゃないのかね。

541 :デフォルトの名無しさん:03/07/04 07:32
>>540
基本的にResultSetからElementの配列作ったり、
RequestParameterからElementの配列作ったり、
Elementの値をDBに格納出来るなら、

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

542 :デフォルトの名無しさん:03/07/04 10:27
>>540のようなアホみたいなクラスを作らないためのGenerics

543 :デフォルトの名無しさん:03/07/04 15:46
>>540
キモイ…。

544 :デフォルトの名無しさん:03/07/04 23:05
>>529は自称アーキテクトに、日々いじめられてる訳か・・・かわいそ。

545 :デフォルトの名無しさん:03/07/06 15:58
遅いレスだが、 >>529
> 俺様謎仕様コレクション
は、いいとして、

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


546 : :03/07/06 17:56
いつ頃からGenericsは使えるの?まだなんでしょ?

547 :デフォルトの名無しさん:03/07/06 18:21
C#みたいにこういうことができないと。
http://pc2.2ch.net/test/read.cgi/tech/1046849844/104

548 :529:03/07/07 04:28
>>545
なんで?

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

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

549 :デフォルトの名無しさん:03/07/07 09:54
>>547
Java の Generics ではできないの?
reflection 周りでそういう機能を実装してくれそうなヲカンがしてるんだが。

550 :デフォルトの名無しさん:03/07/07 12:28
>>549
できない。VMもバイトコードも変更しない方針をとったから。
List<String>とList<Integer>には親子関係も兄弟関係もないただの別クラスになる。

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

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

552 :デフォルトの名無しさん:03/07/07 14:43
>>551
つまり、チミはList<Integer>とList<String>が何の関連もない状態がオブジェクト指向的に正しいと思ってるわけですね。

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

554 :551:03/07/08 07:46
>>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(←あくまでイメージね)
以上の関連があるようにも、必要にも思えないんだが。
何か俺の知らない素晴らしい機能でもあるのかね?

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


555 :553:03/07/08 18:46
>>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>が*互いに*代入可能だそうだ。

556 :デフォルトの名無しさん:03/07/08 18:56
メソッドの引数・パラメータやフィールドの型が違うのにそれはまずく無いか?

557 :デフォルトの名無しさん:03/07/08 19:21
>>554
Genericsは厳密な型の継承ではなく特性の共有を可能にするわけだ。
List<Integer>とList<String>には今までのJava的な視点からは何の関連も無いが、
何かのコレクションであるという性質は共通してる。

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

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

558 :デフォルトの名無しさん:03/07/08 19:22
>>555
それ GJ っつー Java Generics の原型になった言語とコンパイラに関する記事みたいだけど。
それって Tiger で追加される Generics と全く同じなんか?

559 :553=555:03/07/08 20:59
>>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でも大丈夫なんじゃないかな。

560 :デフォルトの名無しさん:03/07/08 21:06
>>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>();
で警告出した方が簡単だと思うんだけど…

561 :デフォルトの名無しさん:03/07/08 21:25
Java Generics の仕様良く知らんのだけど
 LinkedList raw = new LinkedList<String>();
ってのは警告もコンパイルエラーも出さないって仕様なの?
それともコンパイラがタコだから警告もエラーも出さないだけなの?

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

562 :デフォルトの名無しさん:03/07/08 22:32
これかな。
http://www.jcp.org/aboutJava/communityprocess/review/jsr014/

563 :デフォルトの名無しさん:03/07/09 06:19
>>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; は警告対象って事で。

564 :デフォルトの名無しさん:03/07/09 07:28
変な糞仕様だな。(プ

565 :_:03/07/09 07:31
http://homepage.mac.com/hiroyuki44/

566 :デフォルトの名無しさん:03/07/09 08:46
>>547
そのために java.lang.reflect.Type ってゆー新しい interface が提供されるみたい。

567 :デフォルトの名無しさん:03/07/09 08:50
> java.lang.reflect.Type
adding_generics-2_0-ea.zip には入ってないみたいだけどね。

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

569 :デフォルトの名無しさん:03/07/09 12:54
>>568
うん、>>562 のリンク先を読んだときに見た。
でも この仕様だと generics 使わないコードとか
既存のコードをコンパイルしたときに警告出まくるよね。

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

570 :デフォルトの名無しさん:03/07/09 13:03
っつか、 >>555 のリンク先にも

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

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

571 :デフォルトの名無しさん:03/07/09 13:16
このadding_generics-2_0-ea.zipだと
for (String s : ys)とか、printf(String fmt, Object[] args...)とか、
シンタックスシュガーが激増しているのはどうなのよ?
(VBみたいな意味での)簡単さの為にGenericsを導入するってのは嫌。
猿でなくてもソースを汚す。つうか、サンが汚してないか?

572 :デフォルトの名無しさん:03/07/09 13:36
> 猿でなくてもソースを汚す。つうか、サンが汚してないか?
基本的には同意。

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

573 :デフォルトの名無しさん:03/07/10 02:33
>>571
sprintfは、java.text.MessageFormatに同じ機能あるよね?
どうしてか、このクラス普及しないんだよなあ…

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

574 :デフォルトの名無しさん:03/07/10 15:27
>>573
MessageFormat ってなんだかんだ言って不便だし。
基本的に空白で右詰できないとか、16進数を扱う NumberFormat が標準で用意されて無いとか。
空白で右詰は ChoiceFormat でやろうと思えばできない事は無いけど…

575 :デフォルトの名無しさん:03/07/11 07:26
>>574
C++みたいにFormatカスケード出来ないからですか?
printfよりSTL互換を搭載して欲しい

576 :デフォルトの名無しさん:03/07/11 08:34
>>575
> C++みたいにFormatカスケード出来ないからですか?
MessageFormat で
> > 基本的に空白で右詰できないとか、16進数を扱う NumberFormat が標準で用意されて無いとか。
が解消されれば必要ない。

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

577 :545:03/07/11 09:17
>>548
遅レスだけど。

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

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

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


578 :デフォルトの名無しさん:03/07/11 09:18
>>575
とりあえず、作ってみようか。君が。

579 :_:03/07/11 09:23
http://homepage.mac.com/hiroyuki44/jaz09.html

580 :571:03/07/11 10:58
>>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) } )
・・・エディタでできることを言語仕様にいれてどうする。

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

582 :デフォルトの名無しさん:03/07/11 22:48
>>581
世の中にはそういう言語仕様上の枝葉のことばかり気にする、
他の言語をメインにしている馬鹿保守主義者が捨てるほどいて、
コッチから擦り寄らないと使ってもらえないんでしょうよ。

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

583 :デフォルトの名無しさん:03/07/12 10:17
>>576
そもそも MessageFormat って国際化のためのものだから、整形用(空白右詰/16進数表記)の
機能が無くてもいいと思うのだが。
// java.util.*Format で用意しろってのは分かるが。

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

>>581
> extends 節がないと extends Object と書いてあるのと同じ扱いになる。
> コンストラクタがないと、ClassName() { super(); } と書いてあるのと同じ扱いになる。
どっちも許容範囲だと思うんだが…。

primitive をオブジェクトにするのと(boxing じゃなく)と operator overload が欲すぃ。


584 :デフォルトの名無しさん:03/07/12 10:41
>>583
> そもそも MessageFormat って国際化のためのものだから、
なるほど。
でも昔は printf の代替として MessgaeFormat を宣伝してたような…

> primitive をオブジェクトにするのと(boxing じゃなく)と operator overload
それって C# ?

585 :ヽ(´ー`)ノ = 583:03/07/12 11:17
// あれ、名前消えた…なんでだ?

> でも昔は printf の代替として MessageFormat を宣伝してたような…
printf 相当の機能がない Java 厨が必死の対抗策として用意した反対意見だと俺は考える。
現に Javadoc には
> MessageFormat は、連結されたメッセージを、言語に依存しない方法で構築するためのものです。
としか書いてない。

> それって C#?
だねぇ。C# も何度か使ったけど、後追いだからそれなりに考えられてると思うよ。


586 :デフォルトの名無しさん:03/07/12 17:04
>>585
>printf 相当の機能がない Java 厨が必死の対抗策として用意した反対意見だと俺は考える。
そそ。Sun のところにも在ったんだよね。
その宣伝に踊らされて頑張って Format 使ってた身としては
今更 Tiger では printf() が使えます、とか書いてあるの見ると複雑な心境…

587 :デフォルトの名無しさん:03/07/12 18:49
Java厨が必死で否定してたC#の機能は全部Sunが認めて取り入れたわけだ。(嘲笑激藁

588 :デフォルトの名無しさん:03/07/12 20:50
>>586
>その宣伝に踊らされて頑張って Format 使ってた身としては
ご愁傷様

589 :デフォルトの名無しさん:03/07/13 05:36
すまん。
Formatと国際化はどう関係があるのかわからんのだが。

国際化用のAPIってResourceBundleだけちゃうの?



590 :デフォルトの名無しさん:03/07/13 23:48
>Formatと国際化

メッセージを出す関数を考えてみよう。
関数の引数の順番は当然固定だ(仮に"S", "O", "V"だとする)。
特定の言語だけ、例えば日本語だけの場合は
そのままつないで「SがOをVしました」とすればいい。

で次にこの関数を英語に対応させようとした場合を考えてみよう。
引数に関係ない部分を英訳して日本語と同じようにつなげばいいじゃないかと
思うかもしれないが、「S Ved O」にならなければならない=語順が違うので
引数の順序を変えないといけないというめんどくささがある。
逆にいうと引数の順序が変えられない場合は不自然な英訳になるか、
あるいはメッセージを出す関数を丸々作り変えないといけないことになる。

そこで固定部分は英訳するだけで済み、しかも引数の順序の変更にも対応している
Format が国際化では必要になるわけだ。

591 :デフォルトの名無しさん:03/07/14 23:31
>>590
ようするにこういうことですな。
---
% make
make[1]: 入ります ディレクトリ
...
make[1]: 出ます ディレクトリ
---

592 :デフォルトの名無しさん:03/07/15 00:07
>>591
おしい、Bundleに置いておくのはこれ

Enter directory {0}
Leave directory {0}

ディレクトリ{0}に移ります。
ディレクトリ{0}完了しました。

593 :山崎 渉:03/07/15 09:53

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

594 :デフォルトの名無しさん:03/07/15 16:47
そーいや *.properties で
prop = ........ \
 ..........

ってやると複数行にかけるって最近まで知らんかった。

595 :デフォルトの名無しさん:03/07/15 16:52
閑話休題
autoboxing についてなんだけど unboxing conversion って何処で行われるのかわからん。

http://jcp.org/aboutJava/communityprocess/jsr/tiger/autoboxing.html
を読むと boxing conversion に関してはは assingment conversion(代入変換) とか
method invocation conversion(メソッド呼び出し変換) 時に行うって記述があるけど、
unboxing conversion の記述は無いんだよね。

596 :デフォルトの名無しさん:03/07/15 17:23
> 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 するしかないと。

597 :デフォルトの名無しさん:03/07/15 17:54
>>596
なるほど。英語苦手なので そこ読み飛ばしてた。

ちなみに adding_generics-2_0-ea.zip だと casting conversion で unboxing されない…

gj.java:10: 変換できない型
検出値 : java.lang.Integer
期待値 : int
int i = (int)integer;

せめて今現在の仕様ぐらいちゃんと実装してくれ…

598 :デフォルトの名無しさん:03/07/15 23:09
adding_generics-eaなんだからGenericsの早期実装じゃないのか?


599 :デフォルトの名無しさん:03/07/15 23:14
early access なのに文句いってもしょうがあるまい。
1.5 が出て実装されてなかったらいうべきだが。

600 :デフォルトの名無しさん:03/07/15 23:25
>>599
っつか、1.5 まで待ってたら仕様が fix されちゃうじゃんか。

unboxing の仕様が >>596 のような事なら、今なら意見言えば反映されるかも知らんのに。
そーゆー意味で、現在の仕様で良いのか議論するためにも early access 版だろーが
現時点の仕様ぐらい実装しておいてくれ(バグがあっても良いから) ってのはそんなに間違ってるのか?

601 :デフォルトの名無しさん:03/07/22 11:58
.NETなんかはF#(OCaml)でgenericsサポートしてるわけだし。

602 :名無しさん♯:03/07/27 14:56
2.2が出てまつよ。

603 :デフォルトの名無しさん:03/07/27 16:26
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> とかやると読み込み専用セットとかになるらしーんだけど…
面倒くさいんで立ち消えになったのか?

604 :デフォルトの名無しさん:03/07/27 16:45
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 ってのはどーなったんだろ…

605 :デフォルトの名無しさん:03/07/27 16:46
> new Vector.add(0); //メソッド呼び出し変換、ok
new Vector().add(0); //メソッド呼び出し変換、ok

606 :デフォルトの名無しさん:03/07/27 16:57
保守

607 :デフォルトの名無しさん:03/07/27 17:11
Javaらしくない仕様だな

608 :デフォルトの名無しさん:03/07/27 17:14
>>607
「Javaらしい仕様」を400文字以内で説明せよ。

609 :デフォルトの名無しさん:03/07/27 17:15
>>607
何が?

610 :デフォルトの名無しさん:03/07/27 17:18
釣られるなよ。

611 :名無しさん♯:03/07/27 17:30
>>603
CHANGESに書いてあるよ。不評だったみたいね・・・。

612 :CHANGES翻訳@英語不得意:03/07/27 18:21
==========> jsr14_adding_generics-2_2-ea

変更は基本的にコンパイラのバグフィクスと安定化のみです。
先のリリース (2_1) は内部向けなので公開されていません。

現在のリリースは 1.4.2 を要求します。
1.4.1 でも動くかもしれませんが、サポートしません。


613 :CHANGES翻訳@英語不得意:03/07/27 18:21
==========> 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 によります。

614 :CHANGES翻訳@英語不得意:03/07/27 18:21
varargs の文法は読みやすさを改善するためにわずかに変更されました。
新しい文法は James Gosling によります。
  void printf(String fmt, Object... args);
このメソッドでは、変数 args は Object[]型です。

boxing および unboxing 変換は、現在 argument conversion としてのみ実装されています。
これはほとんど JSR 201 エキスパートグループが指定するものではありません。
プロトタイプは JSR 201 からより多くの指示を受けるまで更新されません。

615 :デフォルトの名無しさん:03/07/27 18:24
こんだけ訳すのに1時間もかかってるよ…
途中で笑点見たりしてたけど…

616 :デフォルトの名無しさん:03/07/27 18:38
>>615
おつ

617 :山崎 渉:03/08/02 02:16
(^^)

618 :山崎 渉:03/08/15 16:24
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

160 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)