07/04/01 22:05:41
>>808
なんかライブラリとNetBeansでプラグイン作りたくなってきた
GUIとのバインディングでもかなり効率よさそうだしな
810:デフォルトの名無しさん
07/04/01 22:41:26
プロパティなど要らぬ！
構文糖・即・悪こそが我々Java厨の共有する唯一の正義ではなかったのか！
それを捨てるというならば、まずtypedefを導入しやがれ
811:デフォルトの名無しさん
07/04/01 23:14:33
Genericsは構文糖じゃねーのかよ
生成されるバイトコードはキャスト使いまくりのものと同じだろ
812:デフォルトの名無しさん
07/04/01 23:28:04
>>810
そんなもん、EoD とか言って autoboxing みたいな構文糖が入った時点で捨てとるような。
813:デフォルトの名無しさん
07/04/02 00:10:56
>>811
乙
814:デフォルトの名無しさん
07/04/03 11:11:13
>>810
何かいまいち語呂が悪いな
というかtyprdefはねえよwww
815:デフォルトの名無しさん
07/04/03 19:05:07
そろそろCloneable（何故かスペルミス）が@SafeCloneアノテーションになったりしないかな
ある程度どのように実装しているか表現できればコードチェックのときに便利だと思う。
copy(Cloneable obj)とかif(obj instanceof Cloneable){/*処理*/}とかそういうことは出来なくなるけど……
816:デフォルトの名無しさん
07/04/03 19:40:24
いやtypedefは欲しい。
Javaで導入されていないのは、sourceが読みにくくなるという理由だろうけど。
817:デフォルトの名無しさん
07/04/03 21:04:57
typedef String MyString;
みたいなのは同じ型の別名を作るだけだから有害だが、
typedef Map<String, List<MyClass<Integer, String>>> MyType;
みたいなのは特別な組み合わせに特別な名前をつけているから有用だと思う。
だから、Genericsありの場合のみtypedefを許すというのはどうだろうか。
818:デフォルトの名無しさん
07/04/03 21:12:11
class MyType extends Map<String, List<MyClass<Integer, String>>>{}
819:デフォルトの名無しさん
07/04/03 21:31:09
>>816
実態が変わるのならきっついのでは？
Javaはすべてダイナミックリンクなわけで
Stringからchar[]への変更とかIntegerからLongへの変更とか現実的ではないし
820:デフォルトの名無しさん
07/04/03 21:38:01
これさー
typedef String MyString;
MyString abc = "sample";
これ、OK にするん？ NG にするん？
821:デフォルトの名無しさん
07/04/03 21:44:12
>>818
それでいけるかー
typedefのためだけにファイルいっこつくるのが許容できるかどうかだな
822:デフォルトの名無しさん
07/04/03 21:51:09
>>821
逆にファイル一個作らない場合、どのソースファイルに記述するか迷わないか？
ひとつのクラス内でのみ使用するというならいいが。
823:デフォルトの名無しさん
07/04/03 21:53:30
>>818
擬似Typedefアンチパターン
URLﾘﾝｸ(www-06.ibm.com)
824:デフォルトの名無しさん
07/04/03 22:27:37
extendsに関してはあまり的を得ているとはいえない批判だな。
公開APIで使うべきではないけど、内部処理で使うには問題はなかろう。
「大規模では・・・」というのも、モジュール境界で使わなければいいだろう。
825:デフォルトの名無しさん
07/04/03 22:33:36
>> 820
OKだろ。
826:デフォルトの名無しさん
07/04/03 22:59:03
>824
当を得る、的を射ると書こうと思ったが
"的を得る"もあながち間違いとはいえないらしい
827:デフォルトの名無しさん
07/04/03 23:09:14
>>820
そんなん言語仕様作ってる連中が居るところで聞かなきゃ意味がない。
どーせやるなら generics のパラメタ型だけじゃなくて
JSR 308 の型へのアノテーションも含めて欲しいけど。
828:デフォルトの名無しさん
07/04/03 23:35:42
typedef派の諸君！ Java7で何かが変わると思ったら大間違いだ！
所詮dolphinなんか、property派のお祭に過ぎない！
我々typedef派にとってdolphinほど馬鹿馬鹿しいものはない！
多数決で決めれば、property派が勝つに決まってるじゃないか！
829:デフォルトの名無しさん
07/04/04 00:16:01
俺は言語使用云々よりもMVMが最も重要だと思う。
MVMさえ実現されれば、デスクトップJavaもサーバJavaもかなりの勢いで道が開ける。
830:デフォルトの名無しさん
07/04/04 00:44:35
俺もそうは思うが、MVMって実装される予定はあるのか？
831:デフォルトの名無しさん
07/04/04 01:12:55
>>828
俺はビビらない
もうちょっと上手くやってください
>>830
俺がずっとヲチしてるとこは年単位で動きナス
URLﾘﾝｸ(research.sun.com)
URLﾘﾝｸ(java.sun.com)
唯一怪しげな情報として引っかかってきたのが
URLﾘﾝｸ(jvmcomm.stage.dev.java.net)
ここによると、MVMは作られた、とのこと。
もしかして、通常権限だとアクセスできない
URLﾘﾝｸ(mvm.dev.java.net)
に何らかの情報が？誰か触った事のある奴居ないっすか？
832:デフォルトの名無しさん
07/04/04 08:41:27
>>823
いい記事を知った
㌧
833:デフォルトの名無しさん
07/04/04 09:33:04
>>828
クロージャー祭りなワケですが。
834:デフォルトの名無しさん
07/04/04 11:59:58
諸君！この言語は最悪だ！
プログラミングだとかコンピュータだとか、
私はそんなことには一切興味がない！
あれこれ改変して問題が解決するような、
もはやそんな甘っちょろい段階にはない！
こんな言語はもう見捨てるしかないんだ、
こんな言語はもう滅ぼせ！
私には、建設的な提案なんか一つもない！
今はただ、スクラッチ＆スクラッチ、0から書き直すことだ！
835:デフォルトの名無しさん
07/04/04 13:45:51
MS儲おつかれさまです。
836:デフォルトの名無しさん
07/04/04 20:03:09
MVMなんかいくら待ったって無駄だっ！
837:デフォルトの名無しさん
07/04/05 01:17:46
>>835
うん、MSは儲かるよ
838:デフォルトの名無しさん
07/04/05 07:55:41
外山ゲイツ
839:デフォルトの名無しさん
07/04/12 20:20:00
JDK7 build11
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
何か地味なビルド。
OpenJDKでのビルド修正に関するFixばかり。
840:デフォルトの名無しさん
07/04/13 15:01:43
NIO2 の草案できたらしい。
URLﾘﾝｸ(d.hatena.ne.jp) より。
841:デフォルトの名無しさん
07/04/13 21:03:32
すげー
日本語版が用意されているという趣向が
ちょっと見てみようかという気になる
842:デフォルトの名無しさん
07/04/18 12:27:47
進歩してるなｧ
URLﾘﾝｸ(journal.mycom.co.jp)
843:デフォルトの名無しさん
07/04/18 20:17:38
JRE仮想化はBEAみたいなハードウェアよりなのが勝つんじゃないかな
844:デフォルトの名無しさん
07/04/18 20:53:59
ところでJavaでCPUのコア数って取得できましたっけ？
845:デフォルトの名無しさん
07/04/18 21:06:02
>>844
次世代関係ないな。初心者質問スレいけ。
846:デフォルトの名無しさん
07/04/19 08:13:46
知らないなら知らないって言えばいいのにｗ
847:デフォルトの名無しさん
07/04/19 21:58:33
JOGLがSEに組み込まれることと、
Uniform Driver Interface対応がされれば
Javaクライアントの未来もあるんだが、
今だサーバ関係ばっかサポートしてるな。
848:デフォルトの名無しさん
07/04/19 22:03:55
JavaSE6でJOGLとの融合する予定だったけど不安定でとめたからな
今のバージョンでOpenGLレンダリングでGLJPanel使うとよくおちる
5.0はまともにレンダリングされなかったけどな
なんかリペイントマネージャがおかしかった模様
JOGL＋GLCanvas自体は安定してるのでゲームでは問題ないけど、
GLJPanelが動くようにならないと復権無理だな
あとは入力インターフェースとして2軸2ボタンでいいのでジョイパッドの正式サポートを
849:デフォルトの名無しさん
07/04/19 23:13:54
「New」IO「2」か。。。どれだけ計画性のないネーミングだっつーの
850:デフォルトの名無しさん
07/04/19 23:31:50
>>849
NIO2は別名なんだろ？
統合か名前が変わるかするだろう
851:デフォルトの名無しさん
07/04/20 10:36:48
>>849
サントリー New Old
852:デフォルトの名無しさん
07/04/20 12:39:51
>>851
あれはわざとやったらしいよ
853:デフォルトの名無しさん
07/04/20 23:37:33
マトリックスの奴の名前だっけか
854:デフォルトの名無しさん
07/04/21 00:43:10
>>853
仁王？
855:デフォルトの名無しさん
07/04/28 06:15:28
言語レベルでの複素数型のサポートっていつやるの？
856:デフォルトの名無しさん
07/04/28 09:15:37
>>851
そうなのか。Sunってなんか変なところでマーケティングが変なこと言い出す気がする。
1.1→1.2→1.3→1.4→5.0→6.0
なバージョニングといい
J2SE→Java SE
といい。
857:デフォルトの名無しさん
07/04/28 09:42:56
いや、たんに世の中のバージョンとあわせただけだよ
sunの文化として0.1がメジャーバージョンアップなんだよ
でもマイナーバージョンアップにしか見えない
だから製品名と内部バージョンとをわけるという他の会社と同じものにあわせた
あと6.0はない、6だ
Java2登場前はただのJavaがあったし、SDKはJDKという名前でまたJDKに戻った
Java2という名前を入れるときに製品名としては2.0にすべきだったのさ
ただそれだけのこと
858:デフォルトの名無しさん
07/04/28 11:14:04
マーケティング周りで散々分かり辛かったから一般消費者向けに分かりやすい製品名にしただけ。
ブランド名はずっとJavaの4文字だし。
JDKに戻ったのもsun内部ではずっとJDKと呼ばれ続け、開発者側もJDKで十分慣れ親しんだため。
そして何より、今はゲイツの相手せずに済むから・・・
J/Directなんて禁句だぜ？
アゝ、なつかしの*7・・・
859:デフォルトの名無しさん
07/04/28 16:05:42
♪ア・ソ～レ
ア・チョン！ ア・チョン！
ア・チョン！ チョン！ チョン！ バカ！
860:デフォルトの名無しさん
07/04/29 00:11:38
XMLリテラルよりヒアドキュメントに対応して欲しいのは俺だけ？
String sql = <<END_OF_SQL
update USER_TBL
set name = ?,
age = ?
where id = ?
END_OF_SQL
861:デフォルトの名無しさん
07/04/29 00:14:26
IDE使っていれば改行を気にすることないから俺は要らんな
862:デフォルトの名無しさん
07/04/29 00:34:43
複素数なんていらないじゃん。
commonsにライブラリあるからそれで十分。
863:デフォルトの名無しさん
07/04/29 08:52:50
>>860
ヒアドキュメントは確かに欲しい
あと、ヒアドキュメント中にJavaの式を埋め込むこともできたらいいな
864:デフォルトの名無しさん
07/04/29 09:17:28
言語でサポートされるなら複素数型は欲しいな・・
865:デフォルトの名無しさん
07/04/29 09:57:06
そういえばCSV(TSV, etc.)を読み書きするためのライブラリが標準でないのが気になった
866:デフォルトの名無しさん
07/04/29 10:20:46
TSVやCSVは環境依存しまくりだからな
ほとんどの場合Excel準拠でいいのだろうが
H2のライブラリを使うという手もある
だが、まずはファイルのコピー等を実装するのが先じゃね？
867:デフォルトの名無しさん
07/04/29 10:47:04
仕様通りのCSVって見た事ないんだが。
カンマで区切る以外はメチャクチャだろ。
868:デフォルトの名無しさん
07/04/29 11:05:13
>>867 仕様ってrfc4180？
869:デフォルトの名無しさん
07/04/29 11:53:46
>>868 4180って後付けだし他のシステムで吐き出したCSVを扱う
ときには全く意味ないよね。
870:デフォルトの名無しさん
07/04/29 12:37:17
後付の規格にあわせていたら過去のソフトとの互換性が取れんからな
どうせやるなら文字コードやどのソフトで出力したかなどメタ情報がほしいね
そのへんつっこんでいくとXMLになるから意味がないのだけれども
871:デフォルトの名無しさん
07/04/29 12:55:08
後付規格以外では、独自規格乱立してんだから互換性取るなんて無理。
RFC準拠の標準ライブラリとかならともかく、
自分とこの独自規格に合ったのが欲しいなら
自前の CSVライブラリ作った方が楽だし簡単。
872:デフォルトの名無しさん
07/04/29 13:07:50
URLﾘﾝｸ(opencsv.sourceforge.net)
これ使ってる。別に困った事はない。というか、ＣＳＶ使うのは止めて欲しい。
問題が解決するわけじゃないが、タブ区切りの方が好み。
カンマより、タブの方が文章中で出てくる頻度が少ない。
というか、明確に項目を区切るための制御文字があってそれを入力できる方がいいなぁ
873:デフォルトの名無しさん
07/04/29 13:08:18
ちょうどCSVってかテキストデータのライブラリ作ってる。
MIMEにあるかIANAに見に行って、RFCも日本語訳参考にしてるから
たぶん仕様的には正確だと思う。
RFC4180についてだけど、セル内改行を LF にすればExcel CSVに対応できる。
しかしAccess CSVは CRLF で、RFC4180と仕様が同じという困ったちゃん。
読み込みは柔軟に、書き出しは目的に合わせて厳密にという対応が必要だね。
874:デフォルトの名無しさん
07/04/29 13:28:53
後付けでもECMA-262とW3C DOMはうまい事まとめてるのにね。
相変わらずMSはオープン標準に従う気はないし。
テキストフォーマットの読み書きといえばODFなんかの文書フォーマット読み書きライブラリが標準拡張くらいであっても良いのにね。
やるとしたらテキストコンポーネントのプラグイン扱いかな。
変なところで妙に充実してるのがjavaのクラスライブラリなんだし。
875:デフォルトの名無しさん
07/04/29 13:29:04
>>873
おれもそのAccessとの対応を対数ヶ月前やった
ダブルクォーテーションの中はあらゆる改行タイプをゆるせばいいだけだったっぽい
動きとしてはAccessのほうが納得しやすい
876:デフォルトの名無しさん
07/04/29 13:35:53
>>874
javaってinterface作るのは好きだけど
SPIを作るのは嫌いって人が多すぎるんだよね。
MP3とかOGGとかSound APIにちょこっとしか準拠してないしｗ
877:デフォルトの名無しさん
07/04/29 13:54:41
>>876
インターフェース作る＝自分でAPI定義
SPIの実装＝定義にあわせて作る
だからまったく別の話じゃね？
878:デフォルトの名無しさん
07/04/29 14:00:48
このルールにあわせろっていうのは好きだが、
ルールに従うくらいなら俺仕様でって奴が多いってこと。
879:デフォルトの名無しさん
07/04/29 21:31:55
>>878
うわ、激烈耳が痛てぇ。 orz
880:デフォルトの名無しさん
07/04/29 23:46:40
>>878
それじゃMSがやってることと同じじゃんか。
881:デフォルトの名無しさん
07/04/30 00:08:54
まぁ、大抵の奴はそう思うんじゃね？
882:デフォルトの名無しさん
07/04/30 00:36:26
>>876
例えば標準のプラグインがヘボいので上書きしたい場合みたいに
他のプラグインと衝突する場合のガイドラインがなかったりするし。
いざ作ろうとすると、SPIまわりはドキュメントが不足してる。
他にも、Sun の標準プラグインに必要なインターフェイスだけしかないとか
java.net.URLStreamHandlerFactory はなんで SPIになってねーんだとか
SPI自体がテキトーに作られてる感が無きにしも非ず。
883:デフォルトの名無しさん
07/04/30 10:26:19
C99では複素数もとっくにサポートされてるのにJavaはダメだね。
コンパイラに実装するのは難しくないだろ。
いろんなComplexクラスとか見ると、また車輪の最発明なのかと思って悲しくなる。
884:デフォルトの名無しさん
07/04/30 10:55:57
ここは・・・
C99なんて仕様だけだろﾌﾟｷﾞｬｰm9
って言えばいいのか？
マジレスもしとくか、複素数を普通の演算子で扱いたいって事なんだろうけど
Javaの流れとしてはXMLリテラルの方が先じゃない？
俺としてはどっちも要らんが。
885:デフォルトの名無しさん
07/04/30 11:42:39
>>883
確かに人それぞれの複素数クラスがあるよね。
886:デフォルトの名無しさん
07/04/30 12:50:02
複数のライブラリを横断的に使ってて、
複素数型がライブラリ毎に違うのが面倒くさいとか
そーゆーケースでもない限り標準APIに拘る必要も無いような。
複素数型入れても今更感が強いし、
下手すると独自規格乱立したCSVに後付標準規格(?)ができたのと同じで
それほど意味がないものになるような気もする。
887:デフォルトの名無しさん
07/04/30 12:55:54
>>884
gccのC99じゃだめなのか？
Javaも無料のコンパイラ使ってるくせに…
888:デフォルトの名無しさん
07/04/30 15:30:34
そんなにCがいいならC使ってればいいんでは？
889:デフォルトの名無しさん
07/04/30 15:56:36
>>883
Complexクラスが標準になればいいだけの話か。
890:デフォルトの名無しさん
07/04/30 16:45:23
複素数リテラルのまえに、BigIntegerリテラルだろ。
891:デフォルトの名無しさん
07/04/30 17:05:27
Wikipediaをwikiって略すな！
同時にWikipedia以外のWikiも盛り上げよう！
892:デフォルトの名無しさん
07/04/30 17:17:46
>>891
携帯するものなんて電話以外にもいくらでもあるのに
携帯電話を携帯って略すのもやめよう
893:デフォルトの名無しさん
07/04/30 17:29:32
>>890
リテラルは知らんけど、BigInteger BigDecimal の演算子オーバーロードは
dolphin で追加されそうな気配はある。>>132 のスライドに入ってるし。
もっとも、目玉は closure と erase erasure だろうけど。
closure というか、function type の実装には
java.lang.function パッケージに引数型+戻り値型を名前にした interface を使うみたいだけど
（ {int=>int} なら java.lang.function.II みたいな名前で int invoke(int) だけを持つ interface）
これ、実行時に生成するなら同じ仕組みで List<String> とかも生成するんじゃないかな。
と妄想中。VM（厳密には ClassLoader？）に手を入れる事になるけど。
で、そっちに時間取られると演算子オーバーロードとかは漏れる可能性もあるもしんない。
894:デフォルトの名無しさん
07/04/30 17:57:08
>>891
seasarスレにカエレ(・∀・)
ま、どうせこのスレとあっちのスレ、中の人は同じだがな。
895:デフォルトの名無しさん
07/04/30 18:23:11
MVMは次に乗らないのか？
スレッドはネイティブ対応しないのか？
あーらんに負けるぞ。
896:デフォルトの名無しさん
07/04/30 18:28:56
> スレッドはネイティブ対応しないのか？
？？？
897:デフォルトの名無しさん
07/04/30 19:25:00
いまだにグリーンスレッドと勘違いしてるんだろう.
898:デフォルトの名無しさん
07/04/30 19:34:54
一瞬Rubyスレかと思ったわい。
899:デフォルトの名無しさん
07/04/30 19:46:22
>>898
ﾉｼ おれもれも。
ところでRuby処理系のネイティヴスレッド化って完了したの？
YARV Ruby でぐぐってみたけど、ささだ先生のところは0.4.1くらいで更新が
止まってるみたいで、最新の状況がよくわからん。
あ、スレちがいか。すまん。
900:デフォルトの名無しさん
07/04/30 20:17:55
>>893
目玉はBigIntegerとBigDecimalだと思うよ
業務アプリだとこの辺頻繁に使うし
901:デフォルトの名無しさん
07/04/30 20:19:27
>>899
そういうときはJRubyに関連付けするのだ
0.9.9がでたのでもうすぐ正式版が登場
つまりJavaVM上でRubyは動かすのが正解
VM起動時間なんてJavaSE6なら2回目以降は0.5秒だから問題ないし
902:デフォルトの名無しさん
07/04/30 20:46:47
>>900
っても、closureの話は聞こえてくるけどBigDecimalの話はあんまし聞こえてこないんだよね。
903:デフォルトの名無しさん
07/04/30 20:53:57
>>902
仕事に絡まないプログラムならそうかもしれんが
仕事では使わないという場面はほとんどないからなぁ。
そして仕事で組んでる場合、次の技術というのに目が行く人は少ない。
目をつけていても発言する場が日本語でできないのなら誰もしないだろうさ。
904:デフォルトの名無しさん
07/04/30 21:24:54
>>903
いや、Sunがどーゆー実装にするとか、JCPでどーゆー提案が出たとか
そーゆー話が聞こえてこないって事なんだけど。
905:デフォルトの名無しさん
07/04/30 21:37:14
JCPとかリードスペックとか現時的に業務に絡んでないやつらが多すぎなんじゃ？
906:デフォルトの名無しさん
07/04/30 21:42:30
>そして仕事で組んでる場合、次の技術というのに目が行く人は少ない。
>目をつけていても発言する場が日本語でできないのなら誰もしないだろうさ。
技術者として終わってるな
907:デフォルトの名無しさん
07/04/30 21:51:54
>>906
じゃぁ始まってるアンタが変えてよ
908:デフォルトの名無しさん
07/04/30 21:56:07
>>905
愚痴たれるんならマ板に行ってやれ。
909:デフォルトの名無しさん
07/04/30 22:04:35
>>906
たとえ真実でも、言ってはいけない事ってのがあってだな……
910:デフォルトの名無しさん
07/04/30 22:28:02
>>906-909
PGが絶対口にしてはいけない一言
ｽﾚﾘﾝｸ(tech板)l50
911:デフォルトの名無しさん
07/05/01 01:55:23
>>889
ライブラリにクラスを追加するとか、演算子オーバーロードが出来るようにするとか
よりも、プリミティブな複素数型を言語に追加してくれってこと。
複素数は機種依存するもんじゃないし、
たとえばFFTや平面座標上の点の計算に活躍する。
912:デフォルトの名無しさん
07/05/01 02:00:43
小数点演算すらソフトウェア実装なのに面倒なことさせるな。
913:デフォルトの名無しさん
07/05/01 07:17:37
> 現時的に業務に絡んでないやつらが多すぎなんじゃ？
現実的に国内で業務システムに絡んでる奴は
頭弱すぎて割り込めないだけ。
914:デフォルトの名無しさん
07/05/01 07:49:23
>>911
> たとえばFFTや平面座標上の点の計算に活躍する。
の用途のために、何故
> プリミティブな複素数型を言語に追加してくれってこと。
が必要なのかわからん。クラスじゃ何でダメなんだ？
あと「プリミティブな」ってVM変更（バイトコードインストラクションを拡張）しろって話？
たぶん、そんな要求してもマトモに相手にされないと思うけど。
915:デフォルトの名無しさん
07/05/01 08:19:29
この人は、単に複素数リテラルと演算子のオーバロードが欲しいだけだと思う。
言葉が不自由なので、自分の要求を正しく伝えられないのでは？
916:デフォルトの名無しさん
07/05/01 08:35:19
>VM変更（バイトコードインストラクションを拡張）しろって話？
言語仕様の追加みたいだけど、どこからVM仕様追加の話になるんだ？
C99のようにゴニョゴニョっとまねして、チャチャッ実装しちゃってくれってことじゃないのか。
まあ、あれば便利だし、有難く使わせてもらうけど。
917:デフォルトの名無しさん
07/05/01 08:42:26
自分で実装してJCPに提案しろｗ
918:デフォルトの名無しさん
07/05/01 08:54:09
演算子をオーバーロードして、BigDecimalの割り算はどうやって丸め指定を表現するんだろ
919:デフォルトの名無しさん
07/05/01 08:56:26
Javaの複素数演算用クラスって、どっかになかったか？
いちいち、引数をとらないといけないし、Fortranなどマシン語レベルの
ライブラリ充実している言語と比べると、スピードが出ないだろうけど、
だからといって、VM仕様から変更は影響が大きすぎるだろ。
920:デフォルトの名無しさん
07/05/01 09:06:24
>VM仕様から変更
だからどうしてVM仕様変更の話になるんだと小一時間（ｒｙ
921:デフォルトの名無しさん
07/05/01 09:14:02
>>920
URLﾘﾝｸ(java.sun.com)
922:デフォルトの名無しさん
07/05/01 09:36:30
>>912
strictfpで宣言しない限り結局はFPUに計算させてない？
923:デフォルトの名無しさん
07/05/01 10:37:21
>>916
>>911 の
> ライブラリにクラスを追加するとか、演算子オーバーロードが出来るようにするとか
> よりも、プリミティブな複素数型を言語に追加してくれってこと。
から。
クラスもダメで、演算子オーバーロードもダメで（たぶんリテラルもダメ）、
プリミティブな型を追加と言われたらバイトコード拡張なのか？ ってのは至極当然。
924:デフォルトの名無しさん
07/05/01 11:13:54
意味なしリクエストは却下
925:デフォルトの名無しさん
07/05/02 04:33:33
>>916
>>921
>>923
それがどうやって実装されるかということを君達がアレコレ妄想する必要はない。
それがあればどう世界が変わるかだけを考えろ！
926:デフォルトの名無しさん
07/05/02 07:43:02
まったく変わらない。
以上
927:デフォルトの名無しさん
07/05/02 08:46:01
>>915
複素数リテラルって何？
3.1i
1 + 2i
"3 + 4i"
とかのことか
それと演算子オーバーロードは、
Complex,Matrixクラスの話題とよくセットで出てくるが、
その程度で演算子オーバーロードを実装するのはコストが
高いなどの論点とは今回は関係ないようだ。
おまえは思い込みが激しいようだな。
928:デフォルトの名無しさん
07/05/02 08:57:25
言語不明瞭意図不明。
929:デフォルトの名無しさん
07/05/02 09:03:14
>>927
>>928
おまえ誰だよ。早く消えちまいな。
930:デフォルトの名無しさん
07/05/02 09:35:38
野次と荒らしは2chの花
931:デフォルトの名無しさん
07/05/02 11:39:25
>>930
ｦﾀとDQNが抜けてるぞ
932:デフォルトの名無しさん
07/05/03 06:00:15
>>925
どう実装されるかはしらんが、プリミティブ型を追加するという時点でVMに手をいれないといけないのは決定だろ。
933:デフォルトの名無しさん
07/05/03 09:20:31
C99だと
struct complex {double real, imag;}
struct complex {double z[2];}
とかで実装されてるんじゃないか。
だからコンパイラの拡張のみでマシーン（VM)の方に手を入れることはない。
というか、一般人が実装のことを考える事自体が意味ないじゃん。
934:デフォルトの名無しさん
07/05/03 09:32:36
配列で大量に計算する用途だとクラスよりC#の値型のようなものがあるとベターだな。
935:デフォルトの名無しさん
07/05/03 09:58:40
>>933
えーと。
結局、プリミティブな複素数型は特に必要がなくてクラスでやってもOKって話かな？
本当に複素数型欲しいなら
現時点でGPLで配布されてる javac に複素数型導入して公開したり、
そのパッチを ksl に投稿してみるとか、
BugDatabaseに行って、RFE出すとか既存のRFEに投票するとか、
その bugID 晒して、皆に投票呼びかけたりとか、
もちっと前向きな行動した方が良いと思うよ。
ここで複素数追加みたいなネタ振られたって、
皆でどーゆー実装するのか妄想して遊ぶぐらいしかできないでしょ。
936:デフォルトの名無しさん
07/05/03 10:09:09
座標上の点の計算には便利そうだ。特に回転とか。
複素数クラスがあってもnewしまくるから遠慮してたけど、
言語に追加されるなら便利そうだけどな。
今のトレンドは言語に複素数を追加することなんじゃないか。
C,D,Pythonは既に言語レベルでサポートしてるし。
937:デフォルトの名無しさん
07/05/03 10:25:59
トレンドってほど支持する流れも否定する流れも大きくないと思うが……
938:デフォルトの名無しさん
07/05/03 10:37:45
>>933
頭悪そう
C99を使ってろ
939:デフォルトの名無しさん
07/05/03 10:53:07
>>936
ちなみに、何を作りたくて複素数型が必要なんだ？
940:デフォルトの名無しさん
07/05/03 10:57:23
>>934
C#の値型は、クラスと比べてどんなメリットがあるの？
コンパイル時に最適化されて
ランタイム負荷が小さいとか？
941:デフォルトの名無しさん
07/05/03 12:34:41
>>940
クラスのオブジェクトに比べ生成と削除のコストが低い。
値型は参照を介せずにスタックに直接値が格納されたり、
配列やクラスのメンバーとして直接その領域に値が格納されるので
ボクシングが発生しない限りGCの必要な実体が作られることがない。
このためプリミティブ型に近いパフォーマンスを発揮する。
942:デフォルトの名無しさん
07/05/03 12:45:20
>>939
必要ないんでしょ。
ってか、実際に複素数型が必要な分野のプログラム組んでる人間が
「演算子オーバーロードよりもプリミティブな複素数型」なんて言うとは考えられないし。
943:デフォルトの名無しさん
07/05/03 14:50:30
>>941
値型ってのが広い範囲を表すからいいたいことがあいまいだぞ
944:デフォルトの名無しさん
07/05/03 15:00:41
下手に構造体チックなものが登場されてもBeanの文化が壊れるから
ByteBufferで我慢が出来ないなら諦めてくれって方針で十分。
945:デフォルトの名無しさん
07/05/03 19:32:28
>>933
だから、それはプリミティブ型じゃないだろ。
946:デフォルトの名無しさん
07/05/03 20:49:44
Ｃ＃の値型みたいなのがほすぃ
って言いたかっただけなんじゃないか、と。
947:デフォルトの名無しさん
07/05/03 21:32:14
>>946
Java に C# の値型みたいなの導入すると
コンパイラ弄るだけじゃすまなくて、それこそ VMの変更が必要なりそうだし。
メソッドの戻り値で値型を使う場合とか。
それに、C# は最初から値型があったから良いけど、
Java の場合は generics 導入しちゃった後だからねぇ。
今から C# の値型みたいなものを追加したとしても
現時点でのプリミティブ型みたいに generics で使えなさそうだし。
948:デフォルトの名無しさん
07/05/03 21:52:46
Javaも遅かれ早かれVMの拡張は必要になると思うのだがいつごろ来ると思う？
949:デフォルトの名無しさん
07/05/03 22:05:05
>>948
おいおい……
バイトコードインストラクションの話ならJSR-292のinvokedynamic追加の検討中。
後は>>893がfunction type関連でVM拡張とか言ってる。
950:デフォルトの名無しさん
07/05/03 22:13:31
>>949
さんくす。複素数の議論でVM拡張は避けるべき的な話が出てたので確認してみた。
別にVM拡張前提で話をしてもかまわないわけだよね。
951:デフォルトの名無しさん
07/05/03 22:21:32
>>950
ここは「次世代Javaの動向」をヲチるスレだから、
新機能追加の要望とか、単なる妄想オナニーなら他所でやってくれ。
952:デフォルトの名無しさん
07/05/03 22:24:40
だれもVM拡張は避けろといってなくて、プリミティブ型を追加するならVM変更という話と、そんな無意味な要求は却下されるよという話が同時進行してただけかと。
953:デフォルトの名無しさん
07/05/03 22:28:41
>>951
ヲチするだけとはどこにも書いてないわけで。
しかも、最初から要望とか妄想オナニーばかりのスレで、950も過ぎてから言ったところで説得力ない。
954:デフォルトの名無しさん
07/05/03 22:32:05
>>953
今回ので言えば、既に >>935 で他所行けって出てるし。
他の話題でも他所行けってのは散々出てるし。
955:デフォルトの名無しさん
07/05/03 22:38:34
つまり、スレの流れについていけなくてわめいてるってわけか。
956:デフォルトの名無しさん
07/05/03 22:41:32
>>953
便所に落書きしても要望だとは思われないよな。普通は。
957:デフォルトの名無しさん
07/05/04 01:17:58
複素数を扱うライブラリがあれば便利だと思うが
言語仕様に含めるのはやり過ぎです。
ところで値型って、VBのByValを指しているの？
958:デフォルトの名無しさん
07/05/04 01:45:44
>>957
ここは予想や感想を述べる場所じゃないとのことなので、
そういう動向は今のところ無いということでおしまいらしい。
値型はVB.NET以降では、ユーザー定義型（Structure）、Enum、クラスを除くVBの基本データ型をさす。
VBのデータ型と.NET(CLR)のプリミティブ型は若干違うから注意。
ここではユーザー定義型（Structure）の意味で使ってる。
.NET(CLR)ではValueType C#ではstruct。
Javaだと参照型以外の型＝プリミティブ型＝値型という理解でいいのかな？（自信は無いが）
あとは質問か雑談スレへとかいわれそうだ。
959:デフォルトの名無しさん
07/05/04 03:50:43
>>956
「普通は。」ってなんだよ 9m(^x^
960:デフォルトの名無しさん
07/05/04 09:51:42
C#：全部ヒープに置いたら遅いだろ！struct導入する！
Java：エスケープ分析で自動的にスタックに置くｳﾏｰ
961:デフォルトの名無しさん
07/05/04 12:14:58
どうもsturct(値型）の話になってるようだけど、なんなら
typedef double complex[2];
でいいじゃん。どう実装されるかなんかはベンダ任せなんだけどね。
962:デフォルトの名無しさん
07/05/04 19:07:54
ベンダ任せなわけがない
963:デフォルトの名無しさん
07/05/04 20:59:25
Hさん、居るよね。
964:デフォルトの名無しさん
07/05/05 21:03:27
MさんとKさんもいるよね。