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

>>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⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン