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

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

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

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

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

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

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.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)