[Java SE 7] 次世代Javaの動向 5 [dolphin]

1 名前：デフォルトの名無しさん [2007/05/12(土) 08:25:15 ] 前スレ [mustang/Java SE 6] 次世代Javaの動向 4 [dolphin] pc11.2ch.net/test/read.cgi/tech/1163986696/ [mustang] 次世代Javaの動向 3 [dolphin] pc8.2ch.net/test/read.cgi/tech/1157227790/ 次世代Javaの動向　２ pc8.2ch.net/test/read.cgi/tech/1147881822/ 【Java】次世代Java・J2SE1.6の動向【Mustang】 pc8.2ch.net/test/read.cgi/tech/1081698555/ 369 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 01:23:17 ] Instant と fully defined な SingleMoment を区別する理由と、 Period と Interval を区別する必要とか、 Duration とか良く分からん。 Duration と Inteval はまだ出来てないみたいだけど。 >>368 も同意っちゃ同意なんだけど、 それって Moment と Period が別になってる理由にはなっても、 Moment や Period のサブクラスが 年、月、日、時、分、秒と 細かく分かれてる理由にはならんよね。 370 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 01:58:25 ] >> 369 >Moment や Period のサブクラスが 年、月、日、時、分、秒と >細かく分かれてる理由にはならんよね。 なんで? Days days = ...; days = days.plus(Days.days(3)); とか具体的な型が決まっていたら安全かつ読みやすいじゃん。 しかしメーリングリストだとなんかいろいろ提案とか出されたり、まだまだな感じがしてきた。 sunの中の人が書いてるが、 blogs.sun.com/yk/date/20070705 既存のAPIとの互換性とか国際化も考えると大変そうだね。 371 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:02:32 ] >>369 後者については type safe のためとか？ もしくは、 Moment moment = build(dayOfMonth(1), hourOfDay(3)); とかやると、毎月 1日午前 3時 をあらわすようになるとか…… 372 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:05:26 ] >>370 おいおい…… 一見型安全かもしれないけど、 それだけだと、逆に Period で 1カ月と3日とか複合的な指定できなくなるんですけど…… 373 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:10:03 ] >>371 あぁなるほど。可変長引数のビルダーメソッドで纏めるとか そーゆー場合には別々のクラスになってないとダメだな。 >>370 これはひどい 374 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:34:16 ] >>372 Periodとしての一ヶ月というのは日数として組み合わせて扱えない気がするが。 375 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:37:46 ] （　ﾟдﾟ）ﾎﾟｶｰﾝ 376 名前：374 mailto:sage [2007/08/24(金) 02:48:29 ] 今のAPIを見る限り、複数のPeriodを組み合わせたPeriodというのはない気がする。 Monthsに関しては月によって日数は変わるので、months.plus(Days.days(3))みたいな計算は書けないと思うが。 しかしCalendarDayはplus(Period...)というのを持ってるので、一ヶ月と3日後とかを計算できると思う。ただMinutesとSecondsとの変換とかできそうな気がするのにできないように見えるのはよくわからない。 377 名前：デフォルトの名無しさん [2007/08/24(金) 02:51:08 ] >>372 そーゆーのは、まだない Interval でやるって話なんじゃね？ しっかし、凄く分かりにくい API だな、これ。 そこそこ経験がある奴でもサンプルコードが無いと一行も書けないぞ。 378 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:55:09 ] >>373 instanceof で比較するところを enum と switch で置き換えれば 良いだけだから、別々のクラスになってる必要は全くなかったりする。 379 名前：374 mailto:sage [2007/08/24(金) 03:03:40 ] やっぱりわかりにくいのだろうか? 変換とかファクトリとかのメソッドがどこにあるかわからず、分かりにくい、というのはあるかもしれないが、 そもそも日付と時間の長さなどを区別して扱うこと自体が複雑で、結局intとかで扱っても値の種類を把握していないといけないのでは。 ある程度、単位を型でエンコードして分かりやすくすることで安全で読みやすいコードになる方がよいと思うのだが... 380 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 05:59:11 ] Sun が NASDAQ での銘柄記号を SUNW から JAVA にかえるんだそうな。 blogs.sun.com/jag/date/20070823 blogs.sun.com/jonathan/entry/java_is_everywhere いや、次世代Javaと関係ないけど。 っつーか、これジョークじゃないの？ 4月1日じゃないけどさ。 381 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 07:09:27 ] Dateみたいな基本的なところに今から手を入れるのがアリなら、 Numberもどうにかしてくれんかな。 やっぱり Integer inherits Double であってほしいし、BigDecimalで 持っている四則演算メソッドはNumberすべてで使いたいが。 382 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 07:17:34 ] >>380 JAVAの株があがったとか下がったとかが問題になってくるわけか。 そしたら、JAVAと大文字で書くやつはJavaのことを知らないという伝説が強くなるわけだ。 383 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 07:43:01 ] >>381 Numerics関係は難しいんだよな、後からいじるの。 非互換の影響が大きすぎて。 仕様お目付け役だった、Guy Steeleさん、この辺が弱い。 384 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 16:04:46 ] 元がSUNWならJAVAWにすればいいのにコンソール出ないし・・・。 385 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 16:57:17 ] >>381 メソッド追加はありでも継承関係は変えられないだろうな 386 名前：デフォルトの名無しさん [2007/08/29(水) 21:26:22 ] そろそろ deprecated のクラスやメソッドを一掃してほしい 387 名前：デフォルトの名無しさん mailto:sage [2007/08/29(水) 22:30:24 ] Cloneable を Clonable に直してほしい 388 名前：デフォルトの名無しさん mailto:sage [2007/08/30(木) 02:13:33 ] creat.... 389 名前：デフォルトの名無しさん mailto:sage [2007/08/30(木) 23:47:25 ] catch必須例外を堂々と無視できるプラグマを追加してほしい。 390 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 03:25:48 ] アホか例外処理の意味ないだろ。 握り潰すことすら面倒くさいか？ｗ 391 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 12:32:21 ] JDK7 build19 ttp://www.java.net/download/jdk7/changes/jdk7-b19.html ttp://download.java.net/jdk7/binaries/ forumで話題になっていた 4811096 Allow mixing of heavy and lightweight components が入った様子。 SwingとAWT混ぜるなっていうのが古い話になるわけだ。 あと、レポジトリ管理、Teamwareを完全撤廃？SCCSキーワードの削除ってのが結構あった。 公開してるのも、Subversionでだしね。OpenSolarisで採用してる、Mercurialはないんだろうか？ 392 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 21:15:56 ] >>390 めんどくさい。 どうでもいいコンソールプログラム書くときは 全部例外がトップレベルに流れて死んでくれていい。 あと、どうせならインタフェースの実装も堂々と無視できるプラグマも欲しい。 適当にnullとか0とかfalseとか、あるいはNotImplementedException投げるとか。 IDEにやらせればいいんだけどさ。 393 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 21:52:53 ] >>392 お前はCの方が合ってるんじゃないか？ つーかその程度の捨てアプリならスクリプトで実装すれば良いだけじゃん。 394 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 22:32:46 ] mainメソッドにthrows ExceptionってすればOK 395 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 02:07:00 ] Javaの例外処理の面倒くささはMatzがどっかで言及してたね 396 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 02:21:10 ] silentClose(Closeable) みたいなメソッド作るとか 使い捨てアプリ作る時は throws Exception つけるとかすれば そこそこ改善すると思うんだけどね 397 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 02:29:38 ] >>395 むしろその例外処理の面倒さがないからこそ 他の言語があぶなっかしくて使えない。 コード品質重視だと特に。 398 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 06:37:06 ] むしろ投げる例外をdoc,code上で明文化されてないと何拾って良いか分からないだろ。拾えないと例外に対処できない。 throw,throwsでthrowable以外が飛んでくるのもおかしいし。 399 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 16:45:03 ] ExceptionはThrowableである。以上。 400 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 09:52:45 ] 例外処理の仕組みが問題というよりも IOExceptionとかSQLExceptionのようなレベルの例外を チェック例外にしてるのが問題だと思う SpringやS2やHibernateなら、これらの例外をランタイム例外にラップしてくれるし JavaEE5ではランタイム例外を多用してるけど 肝心の、JavaSEのコアなAPIがチェック例外だらけだからな >>397 現実には、Javaのチェック例外記述のめんどくささに嫌気がさした開発者が catch (Exception e) { e.printStackTrace(); } とか書いて、返って品質悪化するパターンの方が高い気がするorz 401 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 11:41:41 ] あと InterruptedException も握りつぶされて困りやすいチェック例外だ あー InterruptedIOException とか、きっと知らんうちに IOException もろとも握りつぶしてる気がしてきた try { ...... } catch (InterruptedIOException e) { Thread.currentThread.interrupt(); } catch (IOException e) { ...... } なんて、書いた覚えがないよ 402 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 11:50:49 ] 例外のためのEffective Javaみたいなのがあれば読んでみたい。 こういうのはお習字の世界だから仕様としてどうこう変えるもんでもないし。 403 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 13:29:09 ] >>400 IOExcepotionとかは>>396みたいなメソッドがあれば解決する問題 後半に関して言えば そーゆー奴は面倒くさいので例外処理しないし 他人のために必要な例外関連のドキュメントも書かない ので検査例外をあってもなくてもそれほど品質は変化しないと思うが 404 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 13:39:45 ] 何が言いたいのやら・・・必死なことだけは解るが 405 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 13:48:59 ] IOExceptionやSQLExceptionがチェック例外なのは当然だろ？ 外部リソースに依存してんだから、チェックし無い方がどうかしてる。 DAOならそれらをcauseにして、DAOExceptionみたいに新たなチェック例外にくるむがよろし。 406 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 13:55:57 ] closeが例外なげるバカなAPI 407 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:04:03 ] close は flush を伴うからエラーが発生する可能性はある 408 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:07:19 ] closeが例外なげるのがバカってどんだけゆとり脳なんだ 409 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:14:18 ] 思うに、チェック例外をキャッチしないと 警告出すだけの仕様だったらどうなっていただろうか？ 410 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:26:33 ] throws SQLException って書いてないのに throw new SQLException() するような 混ぜるな危険メソッドが書き放題で検査例外の意味がなくなる。 それでいてソースに SuppressWarnings("ignorecheckedexception") とか コンパイル時に -ignorecheckedexception とか必須だと手間がかかるだけ。 中途半端で役に立たないソリューションの見本だな。 411 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:30:17 ] んなもんソースレビューで片付けろよ 412 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:44:28 ] closeが検査例外を投げるバカなAPI 413 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:49:51 ] >>411 第三者の作ったライブラリやフレームワーク使う時は それらも全部ソースレビューすんの？ 414 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:51:10 ] 必ずソースが見れるとは限らんし 415 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:05:42 ] >>405 IOExceptionとかって多くの場合リカバリできるの? リソースの解放はfinallyでやるからチェック付き例外とは関係ないと思うし なるべく例外がチェックできるべきだという意見は多い様に見えるが、一般的にそれらの例外がほとんどリカバリできる処理を書けないならば >>400の言うようにAPIの設計の問題では? 416 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:10:27 ] ソケット使って読み書きしてる時にIOExceptionが発生したらリトライするとかあるよね 417 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:53:29 ] >>416 そういう特定の事情のために、すべてのIO処理で面倒なコードを書かないといけないのはアホ 418 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:56:09 ] というか、例外が出ないコードで例外の補足が必要になるのが、設計ミス System.in.read() とか 419 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:57:17 ] 面倒っても、throws IOException を宣言するくらいのもの。 その場で対処しない例外は上へ送る。 420 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:02:53 ] System.in.read() ってプラットフォーム側の標準入出力の実装方法によっては 例外が出る可能性があるんだが 421 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:10:33 ] 俺としてはNumberFormatExceptionが実行時例外なのが許せないくらいなんだが。 外側のことは一切信用しないという性悪説プログラミングが心情だとね。 422 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:18:48 ] 俺はUserTransactionのメソッドを使ってみたとき、 Javaのチェック例外は、API側が使い方を根本的に間違ってると痛感したよｗ 423 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:24:01 ] >>412みたいな事を言う奴から間違ってると言われても 424 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:31:07 ] >>419 それで上へ送った例外は結局どうなるわけ? throws IOExceptionをまき散らして、 RuntimeExceptionになるか握りつぶされるぐらいじゃないの? >>421 一切信用しないというのはいいが、それはどうやって処理される? 他の値で代用するのは多くの場合問題がある気がするし、 再度入力を促すことになると思うが、 可能な場合と不可能な場合(処理を中断するしかない場合)があると思う ...NumberFormatExceptionに関しては微妙な気がしてきた RuntimeExceptionでよい場合も多いと思うが... 425 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:54:22 ] 最近じゃ例外もAOPで処理するし、リソースはfinallyで閉じるからあまり関係ないしな matz氏がブログで、例外をぎりぎりまで捕捉しないのがRuby流って書いてたけど 結局はそれがいちばん効率的で、開発者に都度catch処理を強制するよりも品質が上がるんだよね。 例外処理がなくても、異常終了で落ちるからテスト時にすぐわかるが、 catchで不用意に握りつぶされた例外はやっかいだし 426 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 17:06:07 ] 何層か下のフレームワーク/ライブラリが投げてくる実装依存の例外もやっかいだけどな。 面倒くさいから検査例外は無い方が良いとか考えてる奴は、 例外関連のドキュメントなんて書かないから品質ズタボロのコードを量産する。 427 名前：424 mailto:sage [2007/09/02(日) 17:27:46 ] >>425 アプリケーション(基本的なライブラリでない)でのチェック付き例外は有用と見られているはずだ アプリケーションレベルではリカバするべき例外を決めることができて、チェック付き例外で強制できる アスペクトを使うことでIO例外をアプリの例外へ変換とかはうまく書けるが、 各メソッドごとの例外処理を常にうまく分離して書けるわけではない テスト時にすぐわかるというのは理由にならないはずだ 再現が難しい例外だってあるから それよりも発生したときなにもできないことが多いというのが理由だと思う 428 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 17:28:11 ] なんか次世代関係なくなってね？ JAVAの例外について勉強するスレとかたててそっちでやれ 429 名前：デフォルトの名無しさん [2007/09/02(日) 18:30:35 ] 例外処理が煩わしいのであれば、 例外処理を包含したテンプレートパターンを適用して処理すればいい。 APIは面倒か面倒じゃないかではなく、安全か安全ではないかが重要。 APIは極力安全に使えるように「馬鹿向け」に作られているが、 本当の馬鹿にはその意味すらわからないらしいｗ 430 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 18:57:24 ] わずらわしいどうの以前にその例外をどう扱うべきかというパターン自体が俺みたいな初心者にはわからない 使われる側でチェック例外を投げてから使う側で遺言を言ったあとRuntimeExceptionでラップするとか、 キャンセルなどの特殊な状況を処理するために使うとか、なんだろうか 431 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 21:40:59 ] 捕捉する場所によって扱い方も異なるとしか言い様がないな。 ライブラリ書いてるなら、抽象的な例外でラップして投げなおすだろうし。 フレームワークならコントローラで一括処理で、それ以外では全部投げっぱなし。 432 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 21:49:00 ] 個人的にはチェック例外＝病気の診断、ランタイム例外＝安楽死とか思ってる で、今直せる見込みのない病人がいるとして、いろんな病院をたらいまわしたり（チェック例外のままthrowsしまくる）、 病気ではないとして放置したり（例外を握りつぶす）、 秘密裏に抹殺したり（System.exit(0)）、 するよりはランタイム例外にして安楽死させたほうがいいような気はするんだけどな。 でもそのあたりの常識やパターンやガイドラインみたいなものがないと実際何をやっていいのか分からないし、 ttp://www-06.ibm.com/jp/developerworks/java/040618/j_j-jtp05254.htmlとか見る限り、 今のAPI仕様でそれが完璧に行われているかというとそうでもない気がする。 どう診断すればいい医者であるか、と言う問題についてはもっと語られてもいい気がする。 433 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 00:54:17 ] 病気になったら即安楽死＝良い医者だと？ 434 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 00:56:05 ] スレ誘導しようとしたらいつのまにか例外処理スレが落ちてた。 435 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 04:46:11 ] >>420 その程度ならRuntimeExceptionで十分 436 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 07:58:03 ] >>435 その程度なら throws IOException 書いておけば十分。の間違いじゃね？ 437 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 08:17:25 ] >>435 もっかい ttp://www-06.ibm.com/jp/developerworks/java/040618/j_j-jtp05254.html 読んでくれば？ 438 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 08:53:56 ] >>432 ロッド＝ジョンソンの本の説明が出てるな 自分も彼のJ2EE本読んで、チェック例外に対する見方を改めた口だ 439 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 11:17:45 ] 例外処理がもれなくSystem.exit(0)オンリーなソースを 押し付けられた俺涙目 440 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 11:21:35 ] 例外処理が全部 System#exit(int) ってのもアレだが、 異常終了してんのに 0戻すってのも相当アレだよな。 441 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 11:36:48 ] 終了するというコードが正しく実行できたので正常！ と。 曲がった先の信号が青だから曲がれる、という理屈に似てます。 >>439 まあ握りつぶされるよりはいいんじゃないか？ 例外処理に関しては、パッケージ単位とか、今度出来るはずのモジュール単位で 包括して処理できる仕組みがあったら便利じゃないかなぁと思う。 442 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 14:31:16 ] >曲がった先の信号が青だから曲がれる、という理屈 これめちゃくちゃ危ないんだが・・・特に内輪差考えないで突っ込んで来る馬鹿な大型車とか。 443 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 22:43:55 ] >>439 脈絡ないけど、exit()の前にfree()は要らないってのを思い出してしまった。 444 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 23:43:03 ] >>432 一理あると思うが、マルチスレッドの場合はランタイム例外もきちんと 捕捉しとかないと握りつぶしたのとたいして変わらないことになるんだよな。 そのへん整合性あるガイドラインならいいんだが。 あと、安楽死というからには本当はやっぱり後始末もちゃんとしておきたいところ。 445 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 14:32:56 ] あのfree論争ってさ、 「とりあえずfreeはしておくべき」的な教条的理想論 「どうせ終了と同時にメモリ開放するんだからいいじゃん、っていうかfreeしたって実際何もしてないのとほぼ同じだし」っていう感じの現実論 って理解でいいんだよな？そりゃ永遠に話は平行線だ罠 446 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 14:37:30 ] 例外ってさ、単純な入力ミスで出るようなはっきりいって例外処理までしてやりたくないようなどうでもいい例外か 出てる時点でもうもうどうしようもない例外が多いような気がする 447 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 15:06:10 ] 外部からの入力ミスなら対処しないとダメだろ。 使い捨てアプリ作ってんなら、throws Exception 付けといて良いだろうし。 448 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 15:16:29 ] >>445 マトモな奴は、free論争なんかする暇があったら他の事をやる。 449 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 15:25:06 ] >>445 >>448 の2つに直交する「どっちでもええがな」論があって、これが現実解。 450 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 15:46:51 ] parseIntで数字じゃなかったときの処理を例外でやんないといけないとか、ひどすぐる。 451 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:05:21 ] >>450 なら、どうしたら良いと思う？ parseInt の戻り型を long にして数字以外なら int の範囲外が返ってくるとか、 parseInt の戻り型を Integer にして数字以外なら null 返すとかしても、 例外よりマシになるとは思えないけど。 452 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:11:43 ] ＞parseInt の戻り型を Integer にして数字以外なら null 返す それやるとオートボクシングしたつもりがヌルポになったりすっからなあ isValidInteger()みたいなチェックメソッドを作ってやるとかどうよ。二度手間だが 453 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:15:34 ] >>452 安全なコードを書くためにそのメソッド使った if文を書くことを強制しないといけない。 ならコンパイラでチェックしてやろうというのが 検査例外な訳で。 どこまで人間を信じるかだな。 454 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:15:42 ] > isValidInteger()みたいなチェックメソッド なんという銀の弾丸 455 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:18:36 ] int[] parseInt(String) 返値は 　{ パースした数字, エラーコード } 俺もparseIntについては何とかならないかと思ってた。 parseできないってのは、想定内の状況だからExceptionにするのはどうかな、と感じてて 例外と言うより１状況として扱いたいと思ってる。 ただ、上のようにしても何かしっくり来ない。 Exception以外に、例外状況をメソッドの返りで扱えるようになればいいな、と思う。 Exception処理が重すぎるというのが元凶なんだが、 RuntimeExceptionでないものに関しては parseIntのように、stackTraceなんて重いものは要らなくて、 その場で処理してしまう例外状況って多いじゃないですか。 何とかならないのかなぁ。 言語構造的に、Throwable一本ってのが簡単なのは分かるんだが・・・ 456 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:25:02 ] >>453 ＞if文を書くことを強制しないといけない。 ここに関しては Nullチェックに対するNullPointerException Iterator#hasNext()に対するNoSuchElementException みたいなRuntimeException派生を投げれば済むと思うんだけど 二度手間なんだよね。このチェック。 457 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:29:35 ] >>456 hasNextはそのチェック自体が軽いからいいけど parseIntは、parseしちゃってるからねぇ・・・二度手間ですよねぇ・・・・ 458 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:29:50 ] >>455 > parseIntのように、stackTraceなんて重いものは要らなくて、 > その場で処理してしまう例外状況って多いじゃないですか。 parseInt の場合だと、 ・ユーザー入力を parseIntした場合はユーザー入力が遅いのでExceptionが重くても問題ない。 ・ファイル読み込んでparseIntした場合、パースできないケースは例外を使うべき状況なので問題ない。 だと思うが。 459 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:33:25 ] 自己レス>>457 あ。parse結果をキャッシュできればいいのか。内部で。 って、コトは、staticメソッドじゃ駄目だな。 Stringのインスタンスメソッドになれば何とかなる、という所か・・・・ 460 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:35:35 ] >>456 要するに、検査例外だと コードがごちゃーとするのがやだから 実行時例外にして欲しいって事でしょ？ どっちにしろ、人間をどこまで信じるかだな。 461 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:37:04 ] >>460 paeseInt の話なら、NumberFormatException は実行時例外だが。 462 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:44:43 ] >>455 最近の言語であるみたいにJavaが多値を返せる言語だったら良かった んだけどなあと思う。 (int, StatusCode) parseInt(String input) とか。 ちょっとキモイが interface ParseResult { } class ParseSucceed implements ParseResult { } class ParseFailure implements ParseResult {} というクラスを用意して、ParseResult型の値を返すとかどうだろう。 463 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:48:13 ] >>462 後半、ただのEnumでよくね？ 464 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:48:49 ] そんなややこしいことやるくらいなら Integer を返して null かどうかで判定できればそれでいいよ 465 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:52:55 ] >>464 だからそういうのやるとコードの変なところでヌルポが出そうで怖いんだって オートボクシングするだけで出るし正体不明のバグ増やすだけ 466 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:56:38 ] じゃあ @CheckForNull 付加で 467 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:57:55 ] >>462 StatusCodeチェックしない場合はパースに失敗してても intの値が得られちゃうし、 その上現状よりキモくなってるしで、あんま良い事ないんじゃね？ 468 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:02:33 ] >>462 多値を返すという話はだーいぶ昔からBugParadeでやられてて 話に参加してみたものの結局、やらないよーという結論。 まあ、どうしてもやりたきゃ、今は配列をつかえってところ。 それなら俺は、配列に違う型を含められるようにしてくれ、と思い・・・ でも、その場合型チェックはコンパイル時には難しいわけで Objectの配列使うのと変わらないわけで・・・・ じゃあ、じゃあstructがあったらいいんじゃ・・・・っていうと、 アレ？それってクラスじゃね？と・・・・ 型チェックが緩くてもともと実行時にしか型がきまらない スクリプト型言語なら、複数返値も考えることあんまり無くていいんだろうけどねぇ 469 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:24:54 ] >>468 いやいや。型に厳しい関数型言語(MLやHaskell)などでは、 昔からタプルという形で多値が扱えたから、それと同等の 仕様にすればいいだけだと思うんだがな。 470 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:28:34 ] >>463 実装は省いたけど、ParseSucceed型からはパーズ結果の値を、 ParseFailure型からは失敗の原因を取得できるようにする意図が あったので、ただのEnumだとよくない 471 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:47:44 ] >>469 >>455 だと Exception重いからException使わないようにしようって話でしょ。 タプルとか使って正常系の処理も重くしたら意味無いんじゃね？ 472 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:55:24 ] >>470 パフォーマンス上の理由なら、そんなもんいちいちnewして返すぐらいなら、例外投げればいいと思う。 単にコードを簡潔にしたいだけなら、 static boolean parseInteger(String text, AtomicInteger out); みたいなのをどっかに用意してやればいい。 AtomicIntegerは、他に標準でintを参照渡しできるインターフェイスが無いからなんで、 適当なintをsetできるインターフェイスならなんでもいいと思う。 コードを簡潔にするっていっても、結局正しくパースできたかのチェックは必要なんだから、 例外で十分でしょ。 473 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 18:06:05 ] しかし事前チェックが出来ないにもかかわらず実行時例外を投げてよろしいものだろうか 同じく文字列を解析して取得するタイプのClass#forNameが発行するClassNotFoundExceptionはキャッチ例外だよね？ 474 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:31:41 ] >>472 パーズ失敗というのは、自分にとっては正常系の処理なんで 例外使うのは違和感があるんだ。感覚的な問題なんだけど、 Map<K, V>#get(K key)がkeyがエントリに存在しない場合に 例外を投げられると嫌なのと似た理由で。 475 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:35:55 ] >>474の補足だけど、Mapから値を取得しようとしたときにキーが存在しない場合 というのは、正常系の処理であることが多いから、もしもJavaのAPIの設計が、 例外投げるようになってたとしたらうっとおしいだろうなあということ 476 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:44:31 ] parseIntの場合も、本音で言うと多値よりnull返す方が良いと思ってる。ただ、 現状のJavaでは、nullを許容する/しないを型で表現できないという欠点が あるので、微妙なところではあるけど。 477 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:46:57 ] はぁ？ 478 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:55:41 ] C#のNullableは安易にstructをサポートしたがために招いた失敗仕様の名残じゃないか オートボクシングでラッパーオブジェクトと用意に相互変換可能な現状で、んなもん無用の長物 479 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 21:53:06 ] 使用できる範囲は限定されるが int parseInt( String numberInString, int defaultValue )があればよかった。 パーズこけたらデフォルト値を返す。 480 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 21:55:44 ] そんなに1行で書きたいんですか 481 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 21:58:55 ] ラッパークラスに例えばisConvertable(String)みたいなメソッドがないのがねぇ。 2回パースするくらいなら例外でいいっしょｗｗｗｗｗｗって設計思想はちょっと。。。。 482 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 21:59:23 ] >>479 ドトネトのTryParseだな。 ttp://www.atmarkit.co.jp/fdotnet/dotnettips/408tryparse/tryparse.html 483 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 22:06:09 ] >>482 Javaだと参照渡しがないし、標準でmutableなintのラッパークラスも無いから作りにくい。 484 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 22:08:38 ] 俺はjava.util.prefs.Preferencesのget()を思い出した 485 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 22:13:18 ] >>483 プリミティブを参照渡しさせない仕様なんだから 可変にしちゃったらラッパークラスにならないぞ 486 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 22:18:43 ] >>483 つ java.util.concurrent.atomic.AtomicInteger っても、atomicな更新のためのクラスだから mutableなintのラッパークラスとして使うのはアレな感じもするけど 487 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:17:23 ] org.omg.CORBA.IntHolder CORBAのクラスなのがあれだが 488 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:25:19 ] >>478 C#のNullableは単に値型でnull許容可能にするための代物。 俺が言ってるのは、値型/参照型区別無くある型の変数に nullを許容する/しないを指定できる代物。しかも、nullableな型は non-nullableの型にそのまま代入しようとしたらエラーになって コンパイラによるチェックを強制されるようなの。具体的な言語で言うと、Nice nice.sourceforge.net/ がそれをサポートしてる。使ってみればわかるけど、この機能はかなり便利。 489 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:36:14 ] ウザいと思われるかもしれんけど、続けて書く。Niceで書くと定義はこんな感じで 書ける。 int? parseInt(String input) {//nullを含む可能性があるint型 　try { 　　return Integer.parseInt(input); }catch(NumberFormatException e) { 　　return null; 　} } 使用する方はこんな感じ。if(parsedValue != null)によるガードが無いと コンパイルエラーになるのでNullPointerExceptionの心配は無い。 int? parsedValue = parseInt(inputValue); if(parsedValue != null) { 　//parsedValueを使った処理 } 490 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:39:25 ] この機能が無いからNullObjectが出来たんだな 491 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:45:26 ] >>489 それ、何が嬉しいのか分からん。 parseInt だと実行時例外で例外処理を強制できないから、 nullチェック強制できる >>489 の方が良いって話？ 492 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:47:05 ] よく考えてみたらオートボクシングめんどくせえなｗ これ 493 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:54:52 ] >>491 パーズ失敗を例外で扱うのに反対で、返り値でパーズ失敗を扱いたいんだけど、 nullでパーズ失敗を表すとしたらNullPointerExceptionの危険性があるし、意図が あいまいになる危険性もある。で、この機能があればnullを許容するという事を 明示できるし、NullPointerExceptionの危険性も無いから欲しいなあということ。 494 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:01:56 ] コンパイルエラーを期待してって考えなら分からんでもない。 javaならメソッド側にアノテーションで実現することになりそうだ。 @NilExclude int parsedValue = parseInt(inputValue); if (parsedValue != null) {     // このブロック以下でのみparsedValueへはアクセス可能 } // このスコープでparsedValueへはアクセスできない をコンパイルすると拡張構文よろしく等価コードに展開されるみたいな感じか。 int parsedValue = 0; Integer parsedValue$ = parseInt(inputValue); if (parsedValue$ != null) { parsedValue = parsedValue$.intValue(); // ... } 495 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:03:19 ] 結論はおまえにはjavaは合ってないって事だな。 話聞いてると考え方が短いコードで実現させるタイプの動的言語の発想だ。 496 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:04:38 ] で、何故parseInt()のパーズ失敗を例外で扱うのに反対かというと、parseInt()は 引数から返り値が一意に定まるので、たとえパーズ失敗でも例外的な状態と 言えないと考えるから。 497 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:06:27 ] >>495 なんで動的言語が関係してくるの？むしろ静的にチェックできる機能が 欲しいって話をしてるわけで、動的言語とは対極の発想だよ。というか、 短いコードが好ましいってのは動的言語特有の発想でもないでしょ。 498 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:07:59 ] > メソッド側にアノテーションで実現することになりそうだ。 メソッド側にってのは余計。構成してて放置したままだった。 499 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:15:42 ] 契約的言語。 500 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:21:29 ] アノテーションひとつで if (n != null) { /* n アクセス */ } と if (n == null) { return; } /* n アクセス */ のどちらかを選択（および強制）できるのなら歓迎かな。 @Overrideの親戚みたいなもんだ。 501 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:43:04 ] 例外を「例外的な状態でのみ使うべき」というのは言葉が同じだからもっともらしく 聞こえてしまうだけで、何の助けにもならない方針。 www.boost.org/more/error_handling.html boost.cppll.jp/HEAD/more/error_handling.html 502 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:48:46 ] >>500 FindBugsをどうぞ findbugs.sourceforge.net/manual/annotations.html 503 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:03:12 ] >>493,496 単に自分の考えと合わないってだけ？ それって自前のクラスメソッド書いて、そっち使うんじゃダメなんか？ なんつーか、>>448-449 あたりが結論になりそうな話じゃねーかと。 504 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:14:56 ] >>503 もちろん自前のクラスメソッド書いて使うことになると思うよ。 実際にJavaプログラム書くときの解決策としては。単に言語の 拡張まで含めて許されるならどういう設計にするのが良いかという思考実験。 あと、free論争とは文脈が違うので一緒にされるのはちと心外だな。 どういう方針でライブラリ設計をするかという話は使い勝手に関わって くる。もちろん、ここで議論しても実際のJava APIの設計が改善されない という意味では無益なのはそうだけど。 505 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:26:05 ] >>496 理解できない すべての失敗する引数はnullが返ることで一意に定まるということ? 例外的な状態かどうかはparseInt単体でなく、呼出し側がどうしたいかでも異なるはずだ デフォルト値が定まる場合と定まらない場合、とか んで、とりあえず保守的にパーズ失敗を例外として扱うと言う設計でよいと思う checkedかどうかは微妙なとこだが 506 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:26:52 ] 単に好き嫌いの問題で、パフォーマンスとか関係ないんでしょ？ free論争と大して変わらんと思うが。 507 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:30:33 ] >>504 parseInt の使い勝手を改善する事により、Java での開発効率が 10％向上するんだ！ とか考えてるなら 一生懸命考えるのも頷けるんだけど…… ぶっちゃけ瑣末な問題じゃね？ 508 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:40:40 ] 例外を握りつぶすユーティリティメソッド作ればOK。 509 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 02:03:58 ] >>505 > すべての失敗する引数はnullが返ることで一意に定まるということ? そういう意図で書いた。正確に言うと、外部の状態に依存せずに 入力*のみ*から返り値が決定される、ということ。その逆の 典型的な例としてはIOExceptionを発生させるような関数や コンストラクタがある。これらの関数は入力だけでなく外部の 状態によって成功したり失敗したりする。 >>507 parseIntだけの問題として考えればぶっちゃけどうでもいいけど、 一般的な問題としてある関数が失敗を返り値で通知するか 例外で通知するか、というのは瑣末な問題じゃないと思う。 510 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 09:42:29 ] ユーティリティメソッド作ればOKってのは、思考停止以外のなにものでもない。 511 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 09:46:39 ] parseInt を改変しようとか考えるのは暇人以外のなにものでもない。 512 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 09:53:09 ] >>511 そうか？ 513 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 10:14:54 ] >>511 つきあってた連中も暇人以外のなにものでもない。 514 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:20:14 ] 改変は、ちゃんと考えてbugparadeにあげるなどすれば、なにがしかの影響は与えられる。 ここで改変について語るのも、そういったヤツのインスピレーションになることもあるだろうし、本人が書き込むこともあるだろう。 無駄ではないよ。 515 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:39:06 ] なにがしかの影響って…… >>509 も parseInt に関してはどうでもいいって言ってるんだが。 そんな瑣末な問題に関わらせる事で JDK開発者のモチベーションを下げたいって事か？ free論争ってさ、やってる当事者は引っ込みがつかなくなってるだけかと思ってたけど 案外、>>514みたいに「この議論は無駄ではない」とか思ってる人も居るのかも知れないね。 516 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:41:41 ] parseIntの例外が例に挙がって - コードを短く書きたい - 例外で扱う状況とは思えない という2点の争点があると思う。 さらに後者の視点は、 - 例外を扱うべき状況を設計の美しさから考える - 例外を扱うべき状況をException処理の重さから考える という2つの立場がある 俺は、parseIntに例外の記述が出てきてもいいが、重いException処理が いやだなぁ、という点から、こういうのがあればいいんじゃないかと思う。 定義済Exception/ StaticException / 短距離Exception /LightWeightException ? 今、Exception処理が重いのは、Exceptionオブジェクトの生成にある（スタックトレース生成など） つまり、生成処理をなくしてやれば大幅にパフォーマンスは改善するはず。 なので思い切って、stackTraceとかが空っぽのExceptionで すぐ直上のcatch節で捉える決まりで、 さらにThrowの必要があるときは別のExceptionにしなくてはいけないようなもの。 気軽に例外が投げられるようになって、正常系の処理が例外でトリッキーに実装されるように なっちゃうかもしれないけど、こういうのってどうですかね。 517 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:47:27 ] >>515 相手にするから調子に乗るんだろ。ほっとけ。 518 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 12:05:24 ] >>516 > 重いException処理がいやだなぁ、という点 いやなだけなのか。 これこれこういう使い方をすると、 （パーズ失敗する）parseInt の呼び出しがボトルネックになって困る、 そして、このような使われ方をする事が多いので標準APIを改善して欲しい、 ってんなら議論の余地もあるけど、それって単なる好き嫌いの問題じゃね？ 519 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 12:39:29 ] >>518 包丁一本で、何でも作るのって大変じゃないかな、って話です。 sourcepost.sytes.net/sourcepost/sourceview.aspx?source_id=29658 のコード書いて、Exception生成のコストを見てみました。 ウチのマシンでの結果です（かかった時間） Try[1]:422 Try[2]:10469 Try[3]:78 Try[4]:10875 １つめが、Throwableを継承して、Overrideで色々ぶった切ったクラス。 ２つめが、単なるException。 ３つめが、単なるObject。 ４つめが、NumberFormatException。 Objectのnewに比べて、Exceptionのが大幅に重い処理となっています。 NumberFormatExceptionもそうです。 もし、ファイルを読む処理をするときに、数字でないものも大量に含むフィールドがあれば Exception処理が時間を食うことが予想されます。 Exceptionの機能を大幅にカットすれば、２桁のオーダーで処理を軽くすることができるわけです。 現在の仕組みを使って、実装するならこうなりますがシステムとしてサポートしてくれても いいかなぁ、と思ったわけで。 520 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 12:53:24 ] >>519 > 数字でないものも大量に含むフィールドがあれば 普通はフォーマットエラー吐いて終わりでしょ。 521 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 13:10:14 ] 　　　　〃〃∩ 　_, ,_ 　　　　　⊂⌒（　`Д´）　＜　ヤダヤダ！ parseInt が例外使っちゃヤダ！ 　　　　　　 ｀ヽ_つ ⊂ノ 　　　　　　　　　　　　　　ジタバタ 　　　　　　〃∩ 　　　　　⊂⌒(　　_, ,_）　＜　ぶっちゃけどうでもいいけど、やっぱりヤダヤダ…… 　　　　　　 ｀ヽ_つ ⊂ノ 　　　　　　　　　　　　　　ﾋｯｸ...ﾋｯｸ... 　　　　　⊂⌒(　　_, ,_） 　　　　　　 ｀ヽ_つ ⊂ノ　　zzz… 522 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 13:56:24 ] delphiのStrToIntDefみたいに、数値にできないときのデフォルト値が指定できればかなりいい 523 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 14:17:51 ] >>520 何で？全部読んで例外をチェックしないと駄目かもしれないですよ。 いや、というか例外を使うなとかいう話ではなく、 パフォーマンスを気にして例外を使うべき場面を回避しようとするのは 本末転倒だから、例外を使わなきゃ駄目なときパフォーマンスが 落ちなければそういう誤解、というか誤用がなくなるんじゃないかと。 524 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 14:45:35 ] >>523 「かもしれない」って…… 要するに、今現在（パーズ失敗する）parseInt の呼び出しが ボトルネックになって困ってるわけじゃないんでしょ。 単なる好き嫌いの問題にしか見えないが。 それに、誤用とか誤解とか言われても…… >>509の理論が いつでもどこでも通用する例外のガイドラインとはとても思えないし、 使い勝手、堅牢性、パフォーマンス、好き嫌いとか色々な要素が絡んでくるから いつでもどこでも誰にでも通用する例外のガイドラインを作るのは難しいだろうし。 525 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 14:47:32 ] ということは例外はこれまでどおりフィーリングとわずかなドキュメントで判断していくしかないのかね 526 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 15:21:46 ] >>524 >>523 ≠>>509です。 parseIntはあくまで例です。 確かにちょっと誤解されそうなレスでした・・・ 誤用というのは、Exceptionを使うまいとして ごちゃごちゃとしたコードになってしまうような状況を指してます。 具体的にカチッとした基準に基づいた「ごちゃごちゃ」ではありませんが。 私は、parseIntに関わらず、Exception処理が軽くなればいいな、という話をしているつもりでした。 527 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 15:36:41 ] >>526 parseInt で例外生成コストが下がると嬉しいか？ それに、parseInt で Exceptionを使うまいとして ごちゃごちゃとしたコードになるって、どんな状況？ あと、俺は Exception処理が軽くなれば良いって要望に対する返答が 「例外的な状況以外で例外使うな」って話なんだと理解してるんだが。 例外って濫用すれば goto より悲惨なスパゲッティコード書けるしね。 528 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 17:31:04 ] パースの失敗は十分、例外的状況に値すると思うが・・・。 例外処理の乱用がスパゲッティーコード招いてるんじゃなくてそういうコード書いてる自分がスパゲッティー作ってるんだと思う。 アプリケーションかミドルウェア側の設計でどうにかなると思うんだが？ 529 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 17:37:48 ] >>527 InterruptExceptionって例外的だと思う？ スレッドのキャンセルを実装しようと思ったら普通に出るけど 530 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 18:49:35 ] >>528 設計っつーか、実装で吸収できるでしょ。 531 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:19:45 ] 便利なら便利なほうがいい。 532 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:24:49 ] 何を便利と感じるかは人によって違う、と。 かと言ってなんでも標準APIに入れたら標準APIメンテする人間の負担が増えて バグが増えたり放置されたりといった悪影響も考えられる、と。 533 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:47:42 ] NICEのnullableってのは興味深いネタだったけど、 それと一緒に語られたparseIntの仕様には何の興味も湧かなかった。 つーことで、イディオム補完型（保証型）のアノテーションの充実を期待したい。 534 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 07:32:33 ] >>445 終了前のfreeは害っていうのがいるだろ。 535 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 07:55:31 ] そんなものは無い 536 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 22:37:51 ] blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx 537 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 22:39:06 ] blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx 538 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 00:14:55 ] parseIntで100近くもダベれるお前らに脱帽 539 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 00:53:35 ] >>536 低脳な質問で悪いんだけど 「クリティカルで速度が要求される場面での数値チェックは、例外を使わないのが無難っぽいです。」 って言ってるけど、じゃぁどういう処理が望ましいんだろうな。 俺も、試しに同じ用なプログラムを10000000回処理をぶん回してみたが、 正直それほど有意差は認められなかった。 ----以下結果---- StringUtils.isNumeric() : boolean で不正な文字かどうかを検知 1回目 451 ms 2回目 401 ms Integer.parseInt() : 例外で不正な文字かどうかを検知 1回目 42822 ms 2回目 42771 ms 540 名前：デフォルトの名無しさん [2007/09/08(土) 01:03:04 ] >>539 例外を使ってるバージョンが100倍近く遅いんだが、それは 有意な差じゃないの？ 541 名前：デフォルトの名無しさん [2007/09/08(土) 01:05:19 ] あ、もちろん実際にparseIntが使われる局面で1000000万回も 呼ばれることは無いだろうから、そういう意味では例外を使っても いいんだろうけど、有意な差が無いってのは変でないの？ってこと 542 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:05:27 ] >>539 ネタにマジレス。 まず 数値チェックに parseInt 使って > クリティカルで速度が要求される場面 が具体的にどういう場面なのかってのを特定するのが先決。 それをしないで「どういう処理が望ましいか」を考えても時間の無駄。 543 名前：デフォルトの名無しさん [2007/09/08(土) 01:07:45 ] 間違った。1000000万回 -> 1000万回 544 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:12:44 ] >>538 まだまだ続くよ 545 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:59:22 ] 巫女巫女ナース巫女巫女ナース♪ 546 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 02:32:19 ] ｢まだまだ　いくよぉ〜｣だな 547 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 03:09:27 ] もうちょっとだけ続くのじゃ 548 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 07:03:01 ] つうか、例外は制御構造の要だろ ttp://d.hatena.ne.jp/smeghead/20070309/baka 549 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 08:05:55 ] 多値にしてもnullableにしても、 失敗をnullで表すのはちょっと古いんじゃないかな。 多値なら失敗(false)したら(undef, false)とundefみたいな値を返す方がいいと思う。 550 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 10:19:24 ] >>544,547 続けるなよ…… 551 名前：519 mailto:sage [2007/09/08(土) 14:09:14 ] >>536 ちょっと待て、ほとんど俺が書いたコードじゃねえかそれ。 ちなみに、おれじゃねえぞ。そのblog 552 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 14:18:22 ] >>549 undefがnullとどう違うのかわからん 553 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 15:06:37 ] >>552 お前はそもそもnullは何をモデル化したと考えてるんだ？ 554 名前：かつのり mailto:sage [2007/09/08(土) 16:03:23 ] 本人降臨っす。 >>519 実験用にパクらせていただきましたｗ ちなみにStringUtils.isNumeric()は微妙ですね。 Integer.parseIntの高速版とするなら、 Integerとしての要件を満たさなければいけません。 正規表現のパターンを予めキャッシュしておいて、 そのパターンでマッチングするのが一番早いのかな。 555 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 16:29:24 ] NumberUtils#isNumberもあるけどlong型とかでも判定しちゃうな 556 名前：519 mailto:sage [2007/09/08(土) 17:34:45 ] >>554 ああ、バッチでファイル読む時は俺もそうしてるなぁ どうせ桁数制限とか入る事が多いし 557 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 17:52:06 ] Patternのcompileってホントにコンパイルしてるの？ 558 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 18:01:25 ] >>557 コンパイルの意味を、パースして実行用データ作っとくって意味なら、コンパイルしてるんじゃねぇの？ 559 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 18:21:18 ] たしかに最適化オプション付きであるとはいってないからね。 Strategyパターンとか駆使してガチガチに最適化されたPatternを返して欲しいとこだ。 560 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 19:03:46 ] Javaの正規表現はDFAでしょ？確か。 DFAはバックトラックしなくていいから、 最適化は高速化ではなく使用メモリのレベル。 遷移テーブルとかその辺。 下手な自前のマッチングコードを書くより早いよ。正規表現は。 561 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 19:55:04 ] >>560 Javaの正規表現はNFA。実装読んでみるべし。 最近の言語に組み込みの正規表現ライブラリの多くはNFA(または その変種)を採用してる。理由はNFAじゃないと扱いづらい機能 (後方参照など)があるため。 562 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 19:56:36 ] ちなみに各言語における正規表現ライブラリの実装がどのように なっているかの概要を知りたい場合は、詳説正規表現がオススメ 563 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 22:35:20 ] >561 そか。情報サンクスコ 564 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 19:28:16 ] DFAじゃあ不便すぎる。 565 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 21:49:32 ] DFAはNFAから変換できるけど、NFAにしておく意義としては、 NFAのまま何かの機能を追加するってこと？ バックトラックする際に後方参照も同時にサポートするためなのか。 566 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 22:28:17 ] >>560 > 下手な自前のマッチングコードを書くより早いよ。正規表現は。 んなわけねーだろ。正規表現遅すぎだ。計測してねーだろ。 ただ、Web アプリとかでせいぜい項目が数百程度の 入力チェックや変換程度なら速度差は計測不能。 567 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 22:41:57 ] >>566 単純な文字パターンの検証なら正規表現の方が遅いだろうけど、 ごく一般的な業務システムプログラマが、 自前で複雑な検証コードを書くよりは速い。 きちんとロジックを書ける人なら速いんだけど。 568 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 23:18:56 ] 文脈的に parseInt でパーズ成功/失敗を予め判定するためのコードでしょ。 >>554が言うように Intergerとしての要件を満たす、 文字列が数字で構成されてるかだけじゃなくて最大値や最小値チェックもするなら 正規表現つかうより自前でやった方が早く書けるんじゃねーの？ 569 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 23:23:20 ] 最大値や最小値をチェックする時点で、成功/失敗を予め判定するどころか、すでに値が求まってる気がする 570 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 23:56:08 ] >>566>>567>>568 >>560は正規表現エンジンがDFAで実装されてる場合の 話をしてると思うよ。その場合なら、下手に自前の コード書くより早いというのは間違いでもなんでもないよ 571 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 00:01:33 ] > ちなみにStringUtils.isNumeric()は微妙ですね。 > Integer.parseIntの高速版とするなら、 > Integerとしての要件を満たさなければいけません。 だからなぁ…… 最大値/最小値チェックしないなら ほとんどStringUtils.isNumeric()で用足りるんじゃね？ 572 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 00:01:37 ] >>565 そういうこと。NFAのままにしておけば、「非正規な」機能である後方参照 やその他もろもろ、比較的容易に追加できる 573 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 00:13:43 ] >>569 例外使わないだけで 100倍程速くなるそうだから、 変換処理が 2回やる事によって 2倍の時間かかっても大した問題じゃないんじゃね？ まぁ、場合によっては大した問題になるかもしれんが。 そんなん問題になってから考えりゃいいっしょ。 574 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 01:42:54 ] 正規表現使うほうが１００倍速いよ。実装が。 575 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 20:17:24 ] C#の正規表現はグループに名前を付けられるみたいだね 576 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 21:14:45 ] >>574 StringUtils.isNumeric()では足りない部分までIntegerの要件を満たすかチェックするんだったら 正規表現でやるのは面倒くさそうだが。 577 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 22:50:21 ] 正規表現のスレでやれよ。ここには関係ないから。 578 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 23:04:10 ] >>576 桁数制限してIntegerの半分以上の範囲捨てるなら簡単だけどな 579 名前：デフォルトの名無しさん mailto:sage [2007/09/12(水) 00:32:10 ] >>575 正規表現のマッチング処理高速化のためにコンパイルすると、 メモリリークするとかＭＳＤＮのドキュメントに書いてあるけどな。 580 名前：デフォルトの名無しさん mailto:sage [2007/09/12(水) 00:53:38 ] >>579 それドトネト1.1のころの制限じゃない？ 581 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 10:08:16 ] なんと言う次世代 582 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 10:59:42 ] 次世代試作機・・・。 583 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 13:48:51 ] Javaを拡張するのではなく、OSを拡張するというのはJSRにならんのかね？ 例えばjinputをJava標準にするための下地にするためにとか。 584 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 14:16:31 ] JDK7 build20 download.java.net/jdk7/binaries/ download.java.net/jdk7/changes/jdk7-b20.html 585 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 19:49:01 ] そういやjdk7が出来たらOpenJDK6をOpenJDK7ベースで再構築してOpenJDK6をGPL2で配布するらしいな。 将来的には公式バイナリも完全にOpenJDKからビルドするらしい。 586 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 12:58:01 ] ７は変な機能増えすぎ もっとシンプルに保てよ 587 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 13:16:10 ] クロージャというか関数導入するならperl見たいな複数戻り値の関数もできるようにしてくれ 588 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 14:09:47 ] 多値返せたらいいのにと思うことはよくある 589 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 15:38:35 ] 時々、妙に多値希望の人っているよね そういう人はロートルだと思っておｋ？ 590 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 15:39:53 ] 多値が返せる言語ってあるの？ 591 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 15:44:03 ] Perlしかしらない。 ただstateとvalueみたいな多値が欲しいがために ReultFooみたいなクラスを書くのはなんだかなぁと思うときは多い。 592 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 16:23:13 ] lispまでいくと多値というよりリストか Object[]のシンタックスシュガーで十分なんだけどな C#のstructなんかよりずっと有用 593 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 17:16:56 ] pythonのtupleみたいなの。 まあ、Object[]でもいいけど。 >>591みたいな 型に名前つけるのが面倒なんだよ。 594 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 19:17:12 ] Pair<A, B> みたいなクラスを作って使いまわすとか 595 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 19:48:49 ] 最近は多値返せる言語増えたよ。 javaだとどうせバイトコードレベルでは配列になるんだろうね。 596 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:16:58 ] public const<String, Boolean> getResult() { return const { "おｋｗｗｗｗ", true }; } こんな感じで死にキーワードを流用できないものか 597 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:20:27 ] >>596 それだったら Pair<A, B> で良いじゃん。 598 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:26:16 ] 普通のGenericsは可変長じゃねー 599 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:36:13 ] じゃ、 static <A, B> Pair<A, B> tuple(A a, B b) static <A, B, C> Triple<A, B, C> tuple(A a, B b, C c) static <A, B, C, D> Quadruple<A, B, C, D> tuple(A a, B b, C c, D d) みたいにすれば？ 600 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:49:41 ] こらこら。Javaにrefやoutはないでしょ。 尤もCommonsLangあたりにはあっていいクラスだとは思うけど 601 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:52:29 ] ref や out って、どこの話だ？ 602 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:52:37 ] 多値よりも Ref<T> のほうがまだ使い勝手が良さそうな気がする。 603 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:53:37 ] ああ、ファクトリメソッドか、俺の勘違い。 >>601 C# 604 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:55:55 ] >>603 いや、レス番の話。 このスレのどこで ref や out の話が出てんのか、と。 605 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:57:38 ] 俺が>>601をクラス定義と勘違いしただけだって。 606 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:59:21 ] あ、>>599ね。あかん、おねむの時間っぽい。 607 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:03:13 ] >>599 にも ref や out があるようには見えんが…… 608 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:04:09 ] どう勘違いしたのかくらい考えろ馬鹿ちん 609 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:07:16 ] なんだ、勘違いか。なら考えても無駄だな。 610 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:09:24 ] 遅かれ速かれ多値はサポートしてくれるものと思いたい。 611 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:10:54 ] JVM系LLで多値サポートしてたら、そっち使えって話になるんじゃね？ 612 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:15:23 ] var rand = new Random(); int n = rand.nextInt(); みたいな書き方も需要あるから、多値もJSRには上がるとは思う。 613 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:17:32 ] bugs.sun.com/bugdatabase/view_bug.do?bug_id=4222792 will not be fixed になってる。 614 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:23:36 ] >>612 どうだろね？ 型推論ですら、変数宣言時の型指定を省くのは Java 的じゃないってんで G<T> g = new G(); みたいに、初期化子の方のパラメタ型指定を省けるようにしようって 論調の方が強いみたいだけど。今までの G<T> g = factoryOfG(); みたいな型推論とも一貫性あるってのが良いらしい 615 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:28:40 ] G<T> g = new(); みたいなのもどっかで見たな。 616 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:31:31 ] 極力interfaceで受け取れいうてる今までとの親和性の問題もあるし、 今後の拡張はローカルキーワードで行きたいって思惑もあるから 早い段階でサポートするならそっちかもな >>615 みたけど流石にそれはないｗ 617 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:42:13 ] varの方はGraphicsEnvironment.getLocalGraphicsEnvironment()とか長すぎるから何とか汁って考えもあったはず 618 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:47:32 ] >>617 つ static import 619 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:49:48 ] staticじゃなきゃ役にたたねーけどね 620 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:52:21 ] メソッド名が長いのはメソッド名のalias導入とかせんと解決せんのでは？ 621 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:54:22 ] 関係ないけど、メソッド名ってたしか長さ制限あったよね 622 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:00:53 ] static importはユーティリティメソッドに 沢山依存してる状態じゃないと返って面倒なだけ 623 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:05:31 ] 名前空間が汚れる。 624 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:06:13 ] まあ、結局のところD言語はvarで解決としたみたいだからJavaもそうなるよ。 プロパティ問題も馬鹿なことやらないで、素直にC#風にしたしね。 625 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:26:52 ] > プロパティ問題も馬鹿なことやらないで、素直にC#風にした ソースは？ 626 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 23:43:33 ] >>590 Common Lisp, Scheme(R5RSから) (define (foo) (values 1 2)) (set!-values x y (foo)) (set!-values q r (quotient&remainder 10 3)) スタックフレームの返値を格納するスロットが一つ増えるだけだから、 tupleやlistやarrayを箱にする方法より性能がいい。 627 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 00:01:39 ] >スタックフレームの返値を格納するスロットが一つ増えるだけだから、 それやると VM の変更が必要にならんか？ > tupleやlistやarrayを箱にする方法より性能がいい。 その辺の性能あげるためにエスケープ解析とか頑張ってるんじゃね？ 628 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 00:02:35 ] >>627 VMの変更っつーか、VM仕様の変更じゃね？ 629 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 00:07:16 ] >>625 docs.google.com/View?docid=dfhbvdfw_1f7mzf2 これの事じゃね？ でも、これbeansのプロパティと互換性ないし、 フィールドとプロパティの名前がかぶった場合どうなるかって部分も甘いような。 630 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 12:14:51 ] 多値はいつか実現して欲しいね。 引数は0個以上なのに、結果は0か1に制限されているのは不便。 >>589 他の言語で使うと癖になるから、粘着的なw要望が続くんだと思う。 631 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 12:20:52 ] >>630 なんつーか、Perlとかで初めてsplitの結果を複数の変数に まとめて入れる表現見たとき便利だと思ったわけで、 こういうのって、返値は配列として扱ってるじゃない。 配列の返値を、各変数に代入するシンタックス糖分があればいいんじゃないかな？ 632 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 13:34:05 ] > スタックフレームの返値を格納するスロットが一つ増えるだけ > 配列の返値を、各変数に代入するシンタックス糖分があればいい この二つって全然別の要求なわけで…… 633 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 13:35:18 ] >>630 粘着的な要望する奴は口だけ動かして手を動かさんからなぁ…… 634 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:09:07 ] >>632 多値って一口に言っても、考えてる事が微妙に違うからなぁ…… 635 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:49:27 ] とりあえず配列でやっておけばいいんじゃないの？ 636 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:52:17 ] >>635 Object[]を使えばいいじゃんって意味？その場合、複数種類の型を内包する配列を扱うことになるから、 言語的なサポートが欲しいって言ってるんじゃない？ 637 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:53:20 ] >>633 このスレに要望出しても意味ねえんだけどな 638 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:54:47 ] 型の問題があるなら、引数のほうに値をうけとる配列として渡すとかね。 639 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:58:05 ] >>637 要望だした時点で気持ちよくなってんじゃないかと。 要望を実現する事よりも、気持ちいい事の方が重要なんじゃね？ 640 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 15:48:10 ] ゆとりのやつって、直接的な効果がなければ意味ねぇとかよく言うよね。 間接的な効果を想像できないんだよね。 641 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 15:53:01 ] あるあるｗ ちょっとたとえを出して、それを否定できただけで、全てを否定ｗ 642 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 15:53:48 ] 間接的な効果に期待（するだけ）しかできないんだったら > 要望を実現する事よりも、気持ちいい事の方が重要なんじゃね？ って評価は正しいような。 643 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 17:26:43 ] はいはい、ここは次世代Javaのスレですよっと JSR-310 に generics版なるものが出来ていた。 https://jsr-310.dev.java.net/nonav/generics/index.html https://jsr-310.dev.java.net/servlets/ReadMsg?list=dev&msgNo=726 > The basic theory is to define a class for each of the basic concepts - > Day, Month, Year, Hour, Second etc, and then utilise those in other > ways. These are TimePart subclasses. > > Instead of having a dedicated Seconds class that holds only seconds, > there is a single TimeAmount class that is generified: > > Standard design: >　 Seconds s = seconds(3); > Generics design: > 　TimeAmount<Second> s = seconds(3); > > Similarly, the field classes such as DayOfMonth are removed with a > single generified TimeField class: > > Standard design: > 　DayOfMonth dom = dayOfMonth(3); > Generics design: > 　TimeField<Day, Month> dom = dayOfMonth(3); 個人的に generics版にするなら var dom = dayOfMonth(3); タイプの型推論が欲しいような。 644 名前：デフォルトの名無しさん [2007/09/17(月) 20:18:05 ] blogs.wankuma.com/kacchan6/archive/2007/09/17/96592.aspx 645 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 08:41:40 ] generics版は、入力めんどすぎだな 646 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 16:45:33 ] ドキュメント簡潔で理解しやすいしこっちのほうが好きなのは俺だけか それはそうと９月の第三月曜日とか毎月第五土曜日（と、第五土曜日が存在するかチェックする方法）とか どうやって入力するんだろう？ この程度のことがいちいち煩雑なのは嫌なんだけど。 曜日指定できそうなCalenderDayのDayOfWeekは引数がなぜかint型だし。 曜日関係はまだまだこれからなのかね？ 647 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 20:37:07 ] あれだ。 カレンダー用のXPathみたいなの作って W3C標準にすればいいんじゃね？ 648 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 21:04:02 ] CQL CalendarQueryLanguage ばばーん >>647 がただ今鋭意作成中です 649 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 23:12:45 ] >>647 Structured Calendar And Time Markup Language 略してSCATML。それのAPIがSCATMLAPI。 650 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 23:19:52 ] 31日や2月29日みたいなTimeFieldやTimeViewって カレンダーが背後にあるクラスに受け入れられるまで、意味のあるカレンダーデータかどうかわかんないわけだよな。 ついでにPeriodを加算するみたいな日付計算もできない。 それなら『カレンダーが背後にあるクラス』をインターフェース化しておいたほうがいいんじゃないかと思ったり。 最初はCalendricalがそうかと思ったんだけどなんか違うっぽいな。 651 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 23:54:39 ] やっぱCalendricalか。何故かTimeViewやTimeFieldに継承されているけどこれは何かの間違いだな。 weekOfMonthが作れるようになったりTimeField同士を結合してTimeViewを作ったりできねえかな。 そしたら今年の９月の第３月曜日とかでも楽に指定できるのに。難しいのかこれは。 652 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 00:00:02 ] TimeAmountで期間データの変換が相互に可能になってるっぽいが Second〜DayはともかくDay〜Foreverのデータはカレンダーないと変換できないような。 いちいちUnsupportedOperationException投げるつもりかいな 653 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 02:32:47 ] こんな感じで書けないかな static import javax.time.Moments.* ... TimeView<Day,Year> leapyearday = build(MonthOfYear(2), dayOfMonth(29)); CarenderYear year = now().currentYear(); List<CalenderDay> lyds = new ArrayList<CalenderDay>(); for(int i = 0; i < 10; i++){ 　　CarenderDay tmp = CalenderDay(year.plus(i), leapyearday); 　　if(!tmp.wasRolledGenerate()) 　　　　lyds.add(tmp); } 654 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 02:54:46 ] >javax.time.Moments.* パッケージ名だけ見たらとてつもなく抽象的すぎて何に使って良いかわかりづらいな。 655 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 03:17:56 ] TimeUtilsとかの方がいいよな。常識的に考えて。 そのうち変わると思うが 656 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 11:16:37 ] >>654 time.Momentsってそんなにわかりにくいかな？ 657 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 13:15:14 ] 個人的にクラス名変えるならこんな感じ 時刻系 TimeView＞TimeExpression：時刻表現 Calendrical＞ScaledTime：カレンダー評価済み時刻表現 TimeField＞TimeField：即値時刻表現 期間系 Period＞Period：期間 TimeAmount＞PeriodField：即値期間 単位系 TimePart＞Unit：単位 その他 Moments＞TimeUtils：ユーティリティクラス うーん、イマイチ。 658 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 16:48:46 ] クラス名・変数名に迷ったら書き込むスレ。Part10 ttp://pc11.2ch.net/test/read.cgi/tech/1180146315/ ここにお願いしてみては 659 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 18:46:41 ] >>656 今のクラス名だと高精度の時間取得APIとも取れるし、時系列系APIのフレームワークとも取れる。 名前から想像できる用途が曖昧で冗長といった印象。 名前からすると一見汎用性がありそうだけど、 けど中身はカレンダーAPIの上位API程度の印象も受ける。 そのため、今のカレンダーAPIとの関係も分かりづらい。 そうなると移行や使い分けが難しいかと。 要するに何のために作ったのか分からん、と・・・。 660 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 19:01:06 ] どう見ても完全に置き換えるものとして使うようにできてるだろ。 互換性を意識しないといけない場合以外は全部移行していいようにするんじゃないのか？ まだOverViewには入ってないがフォーマッティングやパーシング用のクラスも作るらしいし。 661 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 19:22:46 ] java.util.concurrent.TimeUnit も忘れないであげて 662 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 13:05:43 ] JSR 277とJSR 291は議論が熱いね。 www.infoq.com/jp/osgi 663 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 10:54:13 ] OSGi関係は熱そうだね。 関わってるところ多いし、影響が大きそう 664 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 18:48:55 ] JDK7、機能はすごい魅力的なんだが、リリースが一年以上先か・・・。 堅実なのはいいことだけど、もうちょっと早くならんかなあ。 665 名前：デフォルトの名無しさん mailto:sage [2007/09/25(火) 01:28:48 ] 目玉機能とされてるJSR-277もまだだし Closureに至ってはJSRすらないしなぁ。 これでリリースまでに全部つっこんできたら十分早いと思うが。 666 名前：デフォルトの名無しさん mailto:sage [2007/09/27(木) 22:46:13 ] 業界的にはまだバージョン4が多数だから早い感じもする。 667 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 00:51:19 ] テンプレート(1.5)、クロージャ(1.7)とくれば、最後に来るのは…マクロ！(1.9予定) すべての言語は最後はlispの一部を再実装する事になるのかと思うと、複雑な気分だな。 668 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 01:00:50 ] バージョン4なんかない。 669 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 02:22:08 ] >>668 R4のことだろ？ 670 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 04:08:52 ] RhinoR4？ライセンスが・・・ｗ 671 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 10:11:40 ] 最後はevalだな。 672 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 11:10:22 ] OSGiじゃないのか？ 673 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 14:32:28 ] JDK7 build21 download.java.net/jdk7/binaries/ download.java.net/jdk7/changes/jdk7-b21.html だって。 ようやくコンパネの縦長が直った。 674 名前：デフォルトの名無しさん mailto:sage [2007/10/09(火) 15:06:09 ] OSGiかなにかのプラグイン機構がJava SEに入るまでまだ一年位あるので、 Javaのスクリプトで代わりをできないかと思ったんですが、 次を読むと普通にできそうですね。 （つまりJavaプログラム実行中に動的に実行コードを入れ替えたい。） JavaからRubyスクリプトを実行する codezine.jp/a/article/aid/1647.aspx?p=3 個人的にプラグイン機構の重要度がかなり下がりました。 675 名前：デフォルトの名無しさん mailto:sage [2007/10/09(火) 15:14:59 ] 普通にクラスローダを使えばいいだけじゃないの？ 676 名前：デフォルトの名無しさん mailto:sage [2007/10/09(火) 15:26:11 ] クラスローダは難しい・・・ 昔OSGiを使ってたときですらクラスローダで苦労した。 確か、setContextClassLoader辺りとか頻発した。 （OSSのライブラリでこれが設定できないので、プラグインから使うために 　ソースを書き換える必要が発生したこともあった。） 記憶が薄れてるけどOSGiが無いとさらに倍以上苦労する感じだったと思う。 677 名前：デフォルトの名無しさん mailto:sage [2007/10/10(水) 02:31:03 ] URLClassLoaderで簡単にJARファイルからクラスを読み込めるから、 プログラム実行中に動的に実行コードを入れ替えるのは簡単だと思うけどな。 678 名前：デフォルトの名無しさん mailto:sage [2007/10/10(水) 08:53:59 ] >>674 Rubyてw Javascript使えよ。最初からSEに入ってんだから。 679 名前：674 mailto:sage [2007/10/10(水) 13:46:54 ] 助言？ありがとうございます。 >>677 setContextClassLoaderは、Jar内のファイルを読むために 基盤とプラグインのJarのClassLoaderを切り替える のに使ってたんだったと思いますが、 URLClassLoaderを使うと簡単にできそうな気がします。 >>678 JRubyは速いと言う記事が目に入ったので 条件反射で調べてみたのですが、 JavaScriptでいいですね。Rubyは殆ど知らないし。 680 名前：674 mailto:sage [2007/10/10(水) 13:49:23 ] ちなみにやりたい事は、 UMLのステートチャート図で状態遷移を定義しXMLを生成する （このエディタは自作する） 実行時はXMLに従って、各状態と遷移時の処理を行う。 基本的に、ステートパターンで実現する。 こんな感じの多目的に使えるフレームワーク作り。 と言う感じで、DIコンテナで普通にできそうですね…。 それが一番早いなｗ 681 名前：デフォルトの名無しさん mailto:sage [2007/10/10(水) 16:20:30 ] >>677 具体的にどういうコードになるの？ クラスローダーは複雑で言ってる事が見えてこない… 682 名前：デフォルトの名無しさん mailto:sage [2007/10/10(水) 16:44:08 ] >> 681 丁度いいページがあったので勝手にリンクさせてもらいます。 ttp://homepage3.nifty.com/satoshis/java/memo.html#extension 683 名前：デフォルトの名無しさん mailto:sage [2007/10/11(木) 03:45:19 ] JRubyは本家と比べて早いって意味だ。 まあ、宗教は自由だぜ！ 684 名前：デフォルトの名無しさん mailto:sage [2007/10/11(木) 09:54:50 ] >>682おお、そういうことか！ 685 名前：デフォルトの名無しさん [2007/10/13(土) 23:07:55 ] そろそろクロージャの仕様決まった？情報まだぁ 686 名前：デフォルトの名無しさん mailto:sage [2007/10/13(土) 23:23:22 ] www.javac.info/ www.javac.info/closures-v05.html www.javac.info/consensus-closures-jsr.html あたりは動いてないね。JCPのJSRのリストにも登録されてないみたいだし。 他の場所では動いてるのかも知らんけど 687 名前：デフォルトの名無しさん mailto:sage [2007/10/13(土) 23:49:45 ] ああ、いろいろプロポーズはあるみたいだけどそれが採用されそう。 688 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 01:16:57 ] 簡単に読み書きできることが重視されるJavaでは導入が難しいのかも。 クロージャに結びつけた変数に対して破壊的操作を行うプログラムを書いちゃうと、 非常に理解が難しいプログラムになる。と某所で言われていた。 689 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 01:28:27 ] staticメソッドとクロージャを組み合わせて制御文みたいなのを作れるのは面白いと思ったけど フォールスルーしないswitch文みたいなのは無理かね 690 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 02:13:48 ] クロージャ、クロージャ言うけどクロージャ導入しても元々クロージャに書き換えるようなメソッドなら コンパイル時にインライン化されてるだろうから人がクロージャ書く意味ってあるか？ JavaScriptも使うからクロージャは大好きだが・・・。 691 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 02:20:41 ] うん、無理っぽいな。できたとしてもがcaseに指定された値が定数かどうかを判別するすべがないから意味ないし String line; while ((line = br.readLine()) != null) みたいなループをfor eachLine(String line : br)みたいには直せそうだ。あんまりいい例じゃないが >>690 コストが低いからクロージャを使うわけじゃないだろ 692 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 03:35:29 ] いいかげんプリプロセッサとはいわんからせめて#ifdefを導入しろよ 693 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 03:46:15 ] ＞＞６９０ わかりやすいから使うんじゃないのか？ いい加減いちいち無名クラスを宣言するのめんどうになってきたよ。 694 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 04:47:24 ] もう関数型のパラダイム全部入れちゃえばいいじゃんｗ 695 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 05:53:53 ] どうせこうなるんなら最初からいれちゃえばよかったのに 696 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 13:56:40 ] クロージャが、多重継承のようにうまく使えば有用だが弊害もある機能だったらどうするんだ？ Javaはハッカー向け言語ではなく一般向け言語なんだし、彼らが誤用しにくい機能であるか検証しなければならない。 697 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 14:24:52 ] どのように有用？ 別に一般向けでないが？ 自分で使いこなせればよいだけだし？ おまえ、キモイ顔しているんだろうな。 698 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 14:27:52 ] >>692 既にあるにはあるだろう。 699 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 14:50:31 ] 根本的には関数型言語のパラダイムを中途半端に取り入れるのが不味いんだろうな。 だれか、両方を統合するようなアイデアを発明してくれればいいんだが。 700 名前：デフォルトの名無しさん [2007/10/14(日) 15:46:57 ] ところで、>>696は一体全体何を主張したかったのだろうか…謎は深まるばかりだ… 701 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 16:55:18 ] >>699 命令型と関数型で、破壊的代入の在る/無しという根本的な前提が異なっているからなぁ。 この大きく異なる前提を乗り越えて上手く使える機構が欲しいね。 702 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 17:07:59 ] 不変なオブジェクトを渡すか防衛的コピーして渡すか変更不可能なビューを渡すかすればいい話なんじゃないのか Immutableオブジェクトを作るときと同じじゃん 703 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 17:09:24 ] その違いがなくなると、命令型と関数型の垣根がなくなってしまうし、いくら欲しくても乗り越える事はできなだろう。 704 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 18:53:24 ] >>688 int な変数を final int[] みたいに似非参照化して 内部クラスや匿名クラスで使えば結局同じ事になるけど、 記述が容易になると初心者が躓く可能性が高いとかそーゆー話？ docs.google.com/View?docid=k73_1ggr36h CICE とかの public int みたいな構文糖の方が良いって話か？ 705 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 18:54:47 ] こんなん考えてみた。 public static <R, T, throws E> R log(T t, Class<T> clazz, { T => R throws E } block) throws E { 　　T proxy = Proxy.newProxyInstance(t.getClass().getClassLoader(), 　　　　　　　　　　　　　　　　new Class[]{ clazz }, 　　　　　　　　　　　　　　　　new InvocationHandler(Object obj, Method method, Object args)){ 　　　　　　　　　　　　　　　　　　StringBuilder sb = new StringBuilder(obj + " : " +method + " : "); 　　　　　　　　　　　　　　　　　　for(Object o : args){ sb.append(o).append(" , "); } 　　　　　　　　　　　　　　　　　　System.out.println(sb); 　　　　　　　　　　　　　　　　　　return method.invoke( obj, args ); 　　　　　　　　　　　　　　　　} 　　System.out.println("Logging Start : " + t ); 　　R r = block.invoke(proxy); 　　System.out.println("Logging End : " + t ); 　　return r; } で、使い方 log(List logList : list, List.class){ 　　//処理 } これでこのブロックの中でだけ特定の変数のメソッド呼び出しのログが取れるはず ちょっといじれば特定のアノテーションのついているメソッドの呼び出しだけに反応するようにもできると思う 706 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 19:27:18 ] そんなに難しく考えなくともecma-262とかScalaがあるじゃないか。 両立は可能だ。 707 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 19:48:05 ] >>705 return method.invoke( obj, args );じゃなくて return method.invoke( t, args );だわ そういやobjはプロキシインスタンスだった 708 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 19:49:58 ] >>704 void hoge(){ 　public int total; 　array.each{int item => total += item;} 　System.out.println("合計は" + total); } とすると void hoge(){ 　final int total[] = new int[1]; 　array.each(new EachRunner(){ 　　public void run(int item){ 　　　total[0] += item; 　　} 　} 　System.out.println(合計は" + total[0]); } と変換されるという案が出てたはず。 709 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 19:53:00 ] >>708 CICEとBGGAごっちゃになってねーか？ 710 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 20:54:04 ] >array.each{int item => total += item;} こういう文は見慣れない奴はインデントに困るだろうな。 array.each{ int item => total += item; } 711 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 21:15:14 ] array.each( 　　{int item => total += item;} ); こういうインデントは？ 712 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 21:35:40 ] >>711みたいに>>710のインデントを知らん奴がいるから混乱するんだ。 713 名前：デフォルトの名無しさん [2007/10/14(日) 21:50:42 ] >>712 インデントにうるさいおまえと一緒だと疲れる 714 名前：デフォルトの名無しさん [2007/10/14(日) 22:33:45 ] インデントにうるさい言語があったよな。おまえはそれを使ってればいい 715 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 22:53:03 ] ぱいそん 716 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 01:28:48 ] 複人数開発でインデントにうるさいのは当たり前だろ。 コーディング規約なんだから。 717 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 01:54:18 ] インデントなんか IDE が勝手にするだろ。 保存時に規約に沿うように自動フォーマット。 気にすんのはエディタ使ってるおっさんだけだ。 718 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 11:38:51 ] 改行位置は勝手にやってくれなくないか？ 719 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 11:50:20 ] 今時のIDEならやってくれなくなくない？ 720 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 12:53:26 ] Eclipse使えば自動フォーマットもすごいカスタマイズできるよ。 改行の位置も、(俺はコードの単位を明示的に分けたいから有効にはしないけど） 設定すればできる、と思う。 721 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 16:43:38 ] 既にインデントは「する」ものじゃなくて「される」ものだろ。 人間がやるのは、内容の記述だけで、その整形は完全にIDEまかせ。 でも、eclipseできれいにインデントできないって理由で、仮引数へのアノテーションをためらう本末転倒な俺ガイル 722 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 17:03:49 ] 細かい事気にしすぎ。 723 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 17:35:52 ] >>721 見やすさのためのインデントはそれでいいんだけど、 Pythonのようなインデント自体が括弧の役割をする言語ではまた別の話だよね。 724 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 17:38:12 ] 人の書いたプログラムなど見ないで済むように偉くなれ。 725 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 17:39:06 ] >>723 とは言っても、Pythonでも見やすいインデント、というのはあるわけで。 726 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 18:05:18 ] ト・コ・ロ・デ JDK7 build22 ttp://download.java.net/jdk7/changes/jdk7-b22.html ttp://download.java.net/jdk7/binaries/ SwingWorkerのスレッドプールを使う処理が書き直されたらしい。 シャットダウンフックを使うようになったとかなんとか。 727 名前：デフォルトの名無しさん [2007/10/15(月) 18:40:16 ] Javaは原則フリースタイル系統の言語だし、インデントはどうでもいいと思うが？ コーディング規約が別にあるとかいうならそれに従うまでだし。 728 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 20:45:32 ] Cとかに比べれば相当コーディング規約はしっかりしてると思うが 729 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 21:48:21 ] しっかりしているのは認めるが、しかしそれは言語仕様ではない。 インデントも含めて、コーディング規約も次世代に入れて欲しいと願っているのだろうか。 730 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 01:17:12 ] >シャットダウンフックを使うようになったとかなんとか。 使い方によってはwinでコケまくりだな。 昔よくフォーラムで流れたjavawからシャットダウンフックが起動しないってのが復活するんじゃない？ 731 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 03:00:16 ] >>729 そこまですると、やり過ぎではなかろうかと思う。 俺はとりあえず括弧とif, for, whileの書式さえ統一されてればいいと考えてる。 732 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 03:16:45 ] まあもういいんじゃないか。そのコーディングとらやの話は。 733 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 10:56:12 ] 20年以上前、ACM SIGPLAN Noticeでも、 インデントの話は禁止になったことがある。 734 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 14:07:05 ] ↓↓↓次世代Javaの動向↓↓↓ 735 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 14:11:07 ] 命名規則とインデントはどうやっても宗教戦争になっちゃうからね。 736 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 17:12:35 ] まあもういいんじゃないか。そのコーディング虎屋の話は。 737 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 21:26:53 ] コーディングとらやの羊羹 738 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 21:53:01 ] とらやの話か。 739 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 01:35:40 ] 虎屋の話と聞いて飛んできますた。 740 名前：デフォルトの名無しさん [2007/10/17(水) 01:51:43 ] どうしてこうも人は争いの種を作ってしまうんだろうか 741 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 01:56:03 ] Javaの世界なのにJava以外の前提（CやC＋＋）を持ち出したのが原因。 742 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 01:58:35 ] 人は人、自分は自分。偉い人には分からないのです。 743 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 02:23:48 ] 誰もC/C++の話はしてないが 744 名前：デフォルトの名無しさん [2007/10/17(水) 02:37:55 ] で、次世代はどーくるわけよ？ 745 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 05:04:25 ] >>742 偉い人には分かるんじゃないか？ん？ 746 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 07:58:18 ] 俺はJavaの標準コーディング規約には満足してるけどな。 C#の、先頭を大文字にする記法や、プライベートフィールドの先頭にアンダーバーを付ける記法に比べれば、 よっぽどスマートだよ。 747 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 08:49:20 ] Rubyを侮辱するのは止めてください。 748 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 11:36:31 ] ﾜﾛﾀ、Rubyのコーディング規約はそうなってるのかｗ 749 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 12:23:57 ] 規約でなく、言語仕様だね。@で始まるとメンバフィールドになる。 750 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 13:07:54 ] 大文字で始まるとimmutable。> Ruby 751 名前：デフォルトの名無しさん [2007/10/17(水) 15:10:32 ] C#はVCと同じくMSのキモサモサが良く出ている言語だと思う 752 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 16:05:50 ] C#で画面を作るとコントロールを描画している過程が見えるからなぁ 753 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 16:13:23 ] C#出たころからｺﾞﾃｺﾞﾃとJavaにいろんな機能がつき始めたよな 754 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 16:16:12 ] 最近のJavaは美しくないというか崩れてきてる感があるな 755 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 16:21:23 ] genericsとannotation(とprintf)くらいで十分だったのにな 静的型言語でgenericsなしとかﾊﾞｶじゃないかと思ってたが今はいらんのつけすぎ 756 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 16:38:36 ] まぁでも早くC#に追いついて欲しいとは思うし難しいところだ 757 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 16:38:40 ] >>754 具体的にどこ？ >>755 といっても数年後にはクロージャとかenumとか使うようになるよ。 758 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 17:27:17 ] 今だに使われるFORTRAN77は不滅だよ 759 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 17:32:40 ] >>754 なんとなくだがいいたいことはわかる。初期の頃の簡潔さは失われつつあるからな。 それでも、頻繁にクロージャ用無名クラスを作ってるようなら、クロージャを導入する意味はあると思う。 760 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 19:16:44 ] クロージャは必須だろ。 プロパティは辞めて欲しいが。 761 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 20:38:25 ] プロパティを作ってほしいとも思うが、セッターゲッターと互換性のないプロパティ作られるのも困る 762 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 22:15:11 ] セッターゲッターと互換性あるプロパティって何？？？ 763 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 22:20:36 ] obj.property = value; が obj.setProperty(value); に、 value = obj.property; が value = obj.getProperty(); に、 展開されるような構文糖プロパティの事じゃね？ 764 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 22:31:18 ] バージョンアップする限りJavaは肥大し続ける。 Java自体が陳腐化するか、 言語として互換性を捨て新たな言語に生まれかわらないとな。 765 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 22:39:36 ] どれだけ互換性捨てるかにもよるけど、新たな言語に生まれ変わらせるぐらいなら Javaを捨てて、JVM用の新言語を立ち上げた方が既存のプログラムに影響少ないし 過去のしがらみ捨ててドラスティックに変えられるしで、良いと思うがね。 766 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 22:47:09 ] それはまだとっておこう。 767 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 22:49:25 ] 新たな言語になったって、 バージョンアップのたびに肥大化し続けるのは変わらんだろうし、 時間が経つにつれ陳腐化するのは止められないだろうし。 768 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 23:10:19 ] Javaのクロージャで拘束変数の扱いはどうするつもりだろ？ 楽なのは匿名クラスと同じでstatic finalな定数だけにするか、 拘束変数は必ずコピーにする方法なのだけど。 769 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 23:37:14 ] 草案によって違う。 本命っぽい BGGA だと、 www.javac.info/closures-v05.html の Closure Literals にある > All free lexical bindings (中略) are bound at the time of evaluation of the closure literal > to their meaning in the lexical context in which the closure literal appears. CICEだと、docs.google.com/View?docid=k73_1ggr36h の III. Local Variables From the Enclosing Scope あたり、 FCM だと、docs.google.com/View?docid=ddhp95vd_6hg3qhc B. Common rules and mechanisms にある > Local variables from the enclosing scope may be accessed, both read and write 770 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 23:51:32 ] BGGA だと、受け取り側が java.lang.RestrictedFunction しかうけとらねーよと明示しておけば、 final がついてない局所変数使ってるクロージャリテラルは変換できなくてコンパイルエラーになる とか、そーゆー制限も考えられてるみたいだけど。 771 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 02:47:35 ] レキシカルクロージャがいいな。 javaはVMも言語もクラスファイル仕様も互換性確保は相当なものだが、ライブラリ詰め込みすぎが悪い。 #rubyは言語界のモルモン教 772 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 03:08:54 ] どの辺りがモルモンしてる？ 773 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 11:08:02 ] 製作者がモルモン教徒 774 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 18:24:15 ] というかruby信者がモルモン信者と同じ臭いがする。 775 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 20:37:37 ] Macユーザーで、はてなユーザーで、rubyユーザーでケータイがMEDIA SKINあたりだったら、 もう半径5mには入りたくない感じ。 聞きたくもない長所の押し売りをえんえんと聞かされそう。 776 名前：デフォルトの名無しさん [2007/10/18(木) 20:49:07 ] それ、なんて宗教？ 777 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 21:13:55 ] >>775 プログラマーはあんましMAC使わないとおもうんだが。 778 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 21:16:36 ] MacもWindowsも使う。 どれかしか使わないというのが、言語論争と同じく不毛な流れかな？ javaもrubyもperlもpythonも適材適所に使えばいいじゃない 779 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 21:45:47 ] >>778 たしかに其れが一番かっこいい。 780 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 21:59:27 ] rubyはperlとpythonのパラダイムに影響受けてるからそっちの分野に食い込んでくるんだよ無理やり。 rubyの影響を受けたGroovyは言語が止まってるから問題ないが。 結局、JRubyとGroovyとJythonはScripting APIに組み込まれるのかね？ 要らん気がする・・・。 781 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 23:46:52 ] JavaFXは偉大 782 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 23:47:28 ] なにが？ 783 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 00:04:32 ] 手元にあればmac使いたけどな。 だけどwinの方が安いからmac使う機会がないだけ。 784 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 00:13:40 ] 普通にlinux使えよ 785 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 00:16:36 ] linuxは普通なのか？ 786 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 00:58:05 ] MacメインでWindowsも使うJava好きのモルモン信者ですが、何か？ 787 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 01:23:42 ] >>777 おいおい、Macはちょっとバージョンアップが遅いとは言え、 JREがプレインストールだし、JDKもインストールCDに付いているぞ。 Javaアプリを配布する環境としては優秀なのだ。 まだ、↓だけどな。 $ java -version java version "1.5.0_07" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing) 788 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 01:46:49 ] アホ。釣られんな。 789 名前：デフォルトの名無しさん [2007/10/19(金) 02:05:16 ] >>777 君、アタマ悪イッショ。 オンモ二デテミ。 君ノ馬鹿サガ… 790 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 02:54:19 ] アホ。釣られんな。 791 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 09:53:36 ] モルモンっていうと家畜の内臓がどうしても思い浮かぶ 792 名前：デフォルトの名無しさん [2007/10/19(金) 23:47:33 ] 未だに1.6が出てなかったのか…＞Mac 793 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 00:26:03 ] 酷い話でしょ？コミュニティに任せた方がいいような気がするよ。 794 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 00:34:37 ] MacでJavaってそんなに使われてる？ 795 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 00:46:49 ] V2Cを動かすのに必須。 これが無くなるとMacを捨てなくては・・・とまでいう重要ソフト。 796 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 01:00:03 ] fx＋bbs2chreaderでいいじゃない 797 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 01:04:06 ] icedteaだっけ？フリー版のないのか 798 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 01:06:55 ] Java SE 6 Update N https://jdk6.dev.java.net/6uNea.html ブラウザプラグインの書き直し ajaxian.com/archives/ken-russell-on-the-new-java-plugin この辺りの改良でクライアントサイドの勢いがついてほしい所だな。 799 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 11:18:05 ] java6のSwingは、結構Windowsのクライアントサイドでも戦える形になってきたかなと思う。 5と6での差異なんて、数ドット単位のデザインの違いが主なんだけど、その数ドットの差が大きい。 あとはスプリットボタン、シェブロンあたりのウィジェットが追加されればなー。 800 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 00:47:19 ] >>798 > The JVM also runs in its own OS process, > so if the JVM crashes it doesn’t affect the browser. へー、便利じゃんって、オイッ！ 801 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 01:14:37 ] このJVMは独自のプロセスでも動くので、 JVMがクラッシュしたとしてもブラウザには影響を与えません。 そんなに変か？ 802 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 10:03:06 ] 今まで、さんざんブラウザを巻き沿いにしてきたみたいだよなw 803 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 10:18:23 ] 巻き添えっていうか、一気に重くなってその負荷で落ちたように見えることは多かったけど。 ブラウザとは別のプロセスで実行できるってセキュリティ的に大丈夫なんだろうか。 ただでさえVistaでUACとかいうややこしいシステムをとってるのに。 804 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 10:27:36 ] ↑大丈夫だからやったんじゃないかね 805 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 11:47:14 ] >>803 まずくなる理由が見つからんが… 806 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 12:25:31 ] >>803 Javaアプレットは、なぜネットワークからダウンロードしてきたコードを実行しても 安全なのか知りたければ、「バイトコードベリファイア」「サンドボックスシステム」 について調べてみるといい。 そうすれば、別プロセスで動作させても安全な理由がわかる。 807 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 12:27:37 ] >>805 Vistaで導入された鬱陶しい機能の一つに、UACとかいうのがある。 これは、セキュリティ対策のために、ブラウザの権限を制限するもんだ。 だから、ブラウザ上から呼び出されたプロセスには、なにかと制限がかかる可能性がある。 特に、ローカルのリソースにアクセスするようなのは、実行できないかもしれない。 まあ、>>804のいうようにわかってやってるはずだから、対策がないわけがないんだけどね。 808 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 17:03:53 ] >>807 >Vistaで導入された鬱陶しい機能の一つに、UACとかいうのがある。 >これは、セキュリティ対策のために、ブラウザの権限を制限するもんだ。 それはIE7の「保護モード」であって、UACではない。 809 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 18:32:03 ] >>808 そうだった。 今思い浮かんだんだが、もしかして保護モードを回避するために別プロセスに分けたのか？ だとしたら、俺が言ってたことはまるで逆だったのか。 810 名前：デフォルトの名無しさん [2007/10/21(日) 19:18:12 ] ↑だからここは君の浅知恵を披露する場ではないようだが 811 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 20:14:23 ] なんで次世代Javaスレに猿が混じっているのか不思議 812 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 10:35:00 ] ↑猿の脳みそを持つ男 813 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 11:58:57 ] ↓ご立派な人登場。 814 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 14:32:22 ] 呼んだ？ 815 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 16:23:51 ] おいおい、俺を差し置いてか？ ゴスリンが、JDK on Mac OS Xについて少し喋ってる。 blogs.sun.com/jag/ 816 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 16:52:06 ] イヤ待て、もっと大変な事言ってないか？ オレには、MacOSXにZonesが載るって書いてるようにも読めるぞ。 流れ的にそう明言してないが・・・ 817 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 18:52:08 ] >>816 Zonesってなに？ 818 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 18:59:43 ] スレ違いだが、 Solaris:BSD:Linux≒Zones:Jail:Vserver 819 名前：デフォルトの名無しさん [2007/10/22(月) 22:37:44 ] ｚ 820 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 04:27:30 ] sunはJava SEの後につく数字をマイナーバージョンとリンクさせているように見えるけど、 メジャーバージョンが上がる時にはどうするつもりなんだろう。 Java 2 SEとかにするのかな 821 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 06:18:24 ] >>820 予想 java version "1.6.0_0x" java version "1.7.0_0x" java version "1.8.0_0x" java version "1.9.0_0x" ・・・わくわく java version "1.10.0_0x" ・・・なんじゃそりゃ〜 822 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 08:57:17 ] >>820 Java 2 Platform, Standar Editionとかぶりすぎ >>821 そういうマイナーバージョンの桁上がりの問題じゃないからw 823 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 10:17:44 ] メジャーバージョンが上がるときの対策 ・Javaのあとに新しいバージョンだとわかるようなコード・名前・別名をつける ・Java自体の名前がかわる ・何事もなかったかのようにバージョン表記統一 824 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 14:30:33 ] >>821 前にlinuxのソフトウェアでndiswrapperっていうのを使ってたんだが、 使用してるバージョンが1.7で、最新のバージョンが1.21だったのを1.2.1だと勘違いして なんでバージョンダウンしてるのかすごい悩んだことがある。 825 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 16:31:30 ] SunOSとSolarisは、 Solaris 7から、SunOS 5.X=Solaris Xって関係で、 5ってのはkernelのメジャー番号。Xは共通の連番。 だからこれからJava/JDKも7, 8, 9, 10, 11と連番が上がっていって、 JVMの実装が大きく変わった時に、 連番とは関係なくJDKのメジャー番号が1→2と予想。 826 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 19:07:24 ] JDK7 build23 ttp://download.java.net/jdk7/changes/jdk7-b23.html ttp://download.java.net/jdk7/binaries/ なんか今回は実質的な進捗なさげだな。 「ソースのスペースを掃除したよ」って。 なんか行き詰まってるときの作業だろ。 でも2週間に1ビルドのペースが出てきたのは評価したい。 827 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 21:05:23 ] クロージャのプロトタイプ発表とかどうとかは、どうだった？ 828 名前：デフォルトの名無しさん mailto:sage [2007/11/09(金) 23:07:29 ] クラス注釈に@RAIIとかサポートされたらいいな。 必ずスタックに乗るように解釈させて、スコープ抜けると必ずfinalizeされる。 メンバ内も含めてthisが代入または引数にされた場合は、コンパイルエラーとするとか。 829 名前：デフォルトの名無しさん mailto:sage [2007/11/09(金) 23:20:54 ] ７は5よりもいろいろと、てこもりで楽しみだな。 830 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 01:50:16 ] >>828 C言語のregisterとかと同じで、最初のうちは最適化義務はなく将来対応するとか言っておいて、 そのうち最適化が進化したので必要ないから無視するよってなるような気もする。 831 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 05:06:57 ] なんかもうJavaはIDE前提の言語として突き進んでほしいなあ。 言語仕様もとにかくIDEでサポートしやすい方向で。 832 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 09:24:07 ] >>828 finalizeされるタイミングを陽に指定できることは除いて、 今やescape解析の仕事です。 そんな時代遅れなものが入るわけがない。 >>831 馬鹿丸出し。 833 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 11:27:07 ] >>832 ゴスリングのこの発言があったタイミングで バカ丸出しと脊髄反射するほうがバカ丸出し www.atmarkit.co.jp/news/200711/07/techday.html 834 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 11:50:46 ] そんなの知ってるw その解釈こそ馬鹿丸出しじゃん。 IDEで出来ることは、IDEでやればいいんだから。 言語を糞仕様にする必要はない。 835 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 13:04:43 ] >>194 Jakarta JJarのことか？ MavenにもJJarは同梱されているんだが 836 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 13:19:03 ] SunはSolaris向けのIPSを発表したしなあ。 opensolaris.org/os/project/pkg/documents/ 最近、言語ごとにパッケージ管理/配布システムがあって困惑気味です。 837 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 19:31:56 ] ここにはエスケープ解析を研究してる奴いるから聞きたいことあれば聞いとけ。 838 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 20:58:50 ] Googleで検索すればすぐでてくる内容しか書かれてないのに研究だと？ 839 名前：デフォルトの名無しさん mailto:sage [2007/11/11(日) 06:30:11 ] クロージャの演算子 => , {int=>int}は他のなかったのかな？もう決定ぽいけど。 {int x=>x+1}とかぱっと見どうかと 840 名前：デフォルトの名無しさん mailto:sage [2007/11/12(月) 15:07:20 ] lambda見なれてしまったから、他はなんでも違和感がある。 だからどうでもいい感じ。lambdaキーワードはあり得ないし。 Haskellみたいに\ってのもどうかと思うしさ。 841 名前：デフォルトの名無しさん mailto:sage [2007/11/12(月) 23:40:09 ] >>839 1.5がでるときにGenerics見て、こんなのJavaじゃねぇって書き込みがいくつかあったよな 今、そんなこと言ってる奴いないだろう。慣れればそれが普通に見えてくるはず 842 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 00:10:57 ] プロパティのアクセス演算子は c->p=x x=c->p で決定なのか？ 843 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 00:40:12 ] >>842 いつの情報だ、それは。 844 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 01:03:03 ] 結局Javaっていっても現状Web用途がメインなんだから Servlet&JSPのほうがもっと良くなってほしい。 JSPがダメすぎてどうにもならない。 845 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 01:08:22 ] JSP、JSF、VelocityServlet、Wicket・・・好きなもの使え。 846 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 01:10:41 ] >>844 ここはSEのスレなんだよ。 そんな呆けだから(ry 847 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 01:36:26 ] >>843 え、古かった？ じゃ、今はなんだよ 848 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:20:28 ] >>846 ていうか標準のView仕様くらいもうSEに含めろっちゅう話やねん。 JSPにしても単なる条件分岐記述するのに別ライブラリダウンロードさせるってどないやねんって話やねん。 スクリプティングサポートする暇あったらテンプレートエンジンサポートしたほうが人気出るねん。 849 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:29:59 ] スクリプトレットの存在も知らなければ テンプレートエンジンはスクリプトエンジンのひとつに過ぎないという実態も知らないのか？ テンプレートエンジンなんぞとっくにサポートされてるっての 850 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:39:48 ] >>849 おい、JSP2.1の時代にスクリプトレット使ってんのかよ・・・ 851 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:41:43 ] お前が使いたいだけだろ、お前って御託だけで使い分けもできないのな 852 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:45:42 ] Java系の開発者って世の中のニーズが読めないやつばっかだよな・・・ 853 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:51:53 ] 典型的なかまってちゃんだな、JCPのこと調べたらJavaは諦めてPHPでもやっとけ 854 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:59:26 ] どっちにしろDerbyなんかSEに組み込むより、Viewのほうが先だろ・・・常識的に考えて・・・ 855 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 03:01:41 ] かまってちゃんとわがままちゃんって同じ匂いがするんだよな。２ｃｈの経験上 856 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 04:23:08 ] >>848 頭悪〜 Web制作板に行きなよ。 このスレはまだ早いよ。 857 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 15:25:07 ] >>82 これには何かぐっと来たぞ 858 名前：デフォルトの名無しさん mailto:sage [2007/11/15(木) 01:06:38 ] >>854 ViewならSwingがあるじゃねぇか。 859 名前：デフォルトの名無しさん mailto:sage [2007/11/15(木) 01:08:16 ] お前らこれ以上XSLTさんを泣かすな 名実ともにSEのViewだろ 860 名前：デフォルトの名無しさん mailto:sage [2007/11/16(金) 18:41:58 ] 名実が伴っているなら泣くこともないだろうw 861 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 18:53:57 ] Extension Methods とか出てる。 gafter.blogspot.com/2007/11/closures-prototype-update-and-extension.html どうなんだろ？ 嬉しい事は嬉しいけど、これって名前空間汚れるような。 これが許されるなら、クロージャも closure.invoke(argument); じゃなくて closure(argument); したい。 862 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 19:04:27 ] D言語にある機能だってのは知ってるけど、この機能の初出って何だろうね 863 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 19:14:58 ] そう書くことで綺麗に気持ちよく書けるものはどれくらいあるのかね 864 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 19:27:54 ] >>863 java.util.List みたいな published interface にメソッド追加するのが主な目的ってのはいわずもがなだけど。 他の使い道ってなんかあるかね？ 865 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 19:44:36 ] 例えばこんな感じのがあれば、それなりに便利だと思うよ。 int UnicodeUtils.getCodePointCount(Charsequence src, int off, int len); int UnicodeUtils.getCodePointCount(char[] src, int off, int len); int UnicodeUtils.getCodePointAt(Charsequence src, int index); int UnicodeUtils.getCodePointAt(char[] src, int index); 866 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 20:02:23 ] >>865 char[] はともかくとして、String も StringBuilder も StringBuffer も、 codePointCount や codePointAt を持ってるはずだぞ。 CharSequence で持ってないのって java.nio.CharBuffer ぐらいか？ 867 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 20:02:25 ] こんなダサイの入れるくらいなら、 Haskellのtype classとかC++のconceptみたいな generic programming支援の機構を入れて欲しいわ。 868 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 20:24:34 ] interfaceで扱う事に意味があるんじゃないの。例えばC#だけど List<E>.ForEach(delegate(E)) みたいなのがあるけど、IList<E>じゃ使えなくて困惑したことがある。 重複したときはエラーかオリジナルのオーバーロードどちらを優先するんだろう。 interfaceのままでもリフレクションで解決とかもいいけど、それは遅くなるか。 869 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 20:35:45 ] >>868 それは published interface の話じゃなくて？ そーいや、C# は 3.0 で extension method 入るんじゃなかったか？ 870 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 20:59:46 ] static importはIDEと相性が悪い印象があってあまり使われてないけど これが導入されたらIDEに第一引数でサーチいかせる感じで使われ出すんじゃないかな。 871 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 21:29:37 ] やっぱpublished interfaceにメソッド追加（したように見せかける）以外に使い道ないんじゃ？ 872 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 21:56:47 ] 内部構造はまったくいじれないしな 873 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 22:09:42 ] Javaってプライドとかないの？ 874 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 22:19:37 ] ttp://java.sun.com/javase/ja/6/docs/ja/api/index-files/index-16.html 無いね。Java7 でもきっと無い。 875 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 22:19:46 ] Javaのプライドって何のプライドよ？ 876 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 23:24:42 ] 言語としてのプライド 877 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 23:27:34 ] なんかアホの子が出現してるな 878 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 11:50:05 ] >>861 > これって名前空間汚れるような。 その点、リンク張られているExpanderの方がまだいいね。 879 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 13:59:55 ] >>875 Java使いが集まって、大晦日に闘う。 880 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 14:17:23 ] Gosling緊急参戦！ とかなら見に行く。 881 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 14:50:30 ] >>879 冗談としては面白くないけど 本当にやったら面白そうだな、それ。 882 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 17:48:38 ] >>881 想像したらわろた 883 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 18:07:02 ] >>879 何で戦うんだよwwwコーディングかwww 884 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 19:52:13 ] JavaOne Tokyoのときみたいに、プロレス 885 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 22:05:45 ] そうね、ここはコーディングでといいたいところを ぐっとこらえて、総合ルールでやってもらった方が 盛り上がるね！ 886 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 23:12:33 ] じゃあ多重継承もfriendも属性も継続もありでいいんだな。 887 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 23:14:37 ] 属性って？ annotation じゃダメなん？ 888 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 10:35:10 ] >>880 Goslingが和太鼓たたきながら、 「本物のプログラマでてこいや！」 889 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 11:18:22 ] 本物のプログラマはPascalを使わない―――Javaも使わない。きっと。 890 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 18:39:40 ] 本物のプログラマだなんてガキみたいなこと言ってるうちは、 その本物のプログラマなるものにはなれんだろうな 891 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 18:57:17 ] 何を使うんだろう。やっぱりLisp？ 892 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 19:37:41 ] >>890 本物のプログラマネタくらいは知っておこうぜ、本物のプログラマならｗ ググればすぐに出てくるよ 893 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 19:37:47 ] ホンモノのプログラマになる極意は、ホンモノの真似をしないことである 894 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 17:06:57 ] ふるいネタだな。キッシュを食わないとかいうヤツだっけ。 895 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 22:21:39 ] ホンモノのプログラマはデスマーチで2chに書く暇などありません。 偽者の人生が楽しい 896 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 23:07:44 ] 業務が設計中心になってからはデスマはないなぁ。 設計工程に現役プログラマが携わらないことの危険性が 頭でもなく心でもなく体で理解したｗ 897 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 01:38:43 ] よほどヘボいSEとやってたんだな。 898 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 13:16:30 ] プログラマーは設計書が全然上がってこねーぞと文句を言っているはず デスマの原因作ってるのはお前だｗ 899 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 21:09:42 ] ↑こいつ文盲？ 900 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 21:13:46 ] うん 901 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 22:11:53 ] 宣言側の拡張メソッドだってさ。 digital-sushi.org/entry/declaration-site-extension-methods/ ユーザ側で拡張すると、メソッド名の衝突とか面倒くさいって話らしいけど。 902 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 22:25:27 ] 宣言側でやっても interface A { void method() import static SomeClass.method; } interface B { void method() import static AnotherClass.method; } class C implements A, B { } があって、 C c = new C(); c.method(); したとき、どっちのメソッド呼ぶかって曖昧さが残るわな。 903 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 01:37:50 ] 曖昧な場合はコンパイルエラーになるだけ 904 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 02:11:30 ] >>901 馬鹿馬鹿しい… 905 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 02:20:12 ] >>903 いや、use-site でも declaration-site でも曖昧なケースが出てくるのは同じじゃねーかって話。 906 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 22:05:42 ] LINQのような糖構文がほしい・・・ やっぱいらない 907 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 23:13:41 ] ハイバーネートだかなんだかのO/R マッピング使ったらええんとちゃう？ 俺もLINQはいらんけど、varはほしいな。 908 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 14:03:49 ] JDK7 build24 ttp://download.java.net/jdk7/binaries/ ttp://download.java.net/jdk7/changes/jdk7-b24.html あれ？変更点からっぽ？ 909 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 16:32:16 ] >>906 今更だが、糖衣構文を糖構文とは略しないでしょ。 910 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 17:05:48 ] syntax sugarを糖構文と訳すのはアリだと思うが。 911 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 17:08:07 ] >>910 マジすか・・・。略語じゃなくて訳の違いだったわけか。 912 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 18:35:49 ] 「糖衣構文」 と 「構文糖」 は聞いたことあるけど 「糖構文」 はあまりないな。 913 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 18:35:52 ] >>910 うーん、それはやめた方がいいと思う。 糖衣構文がうざければ、シンタックス・シュガーでいいし。 914 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 21:23:36 ] >>908 JDK6u3と比べて、アプリケーションのメモリ消費量が減っているような気がする。 915 名前：デフォルトの名無しさん mailto:sage [2007/12/11(火) 01:19:49 ] Java SE 6 Update N Early Access build 08キタ。新しいJava Plug-Inが入った模様。 JDK 6u10 build b08 https://jdk6.dev.java.net/6uNea.html download.java.net/jdk6/6u10/promoted/b08/changes/jdk6uN-b08.html 916 名前：デフォルトの名無しさん mailto:sage [2007/12/11(火) 13:13:20 ] >>908 b23 と b24 は TeamWare から Mercurial にリポジトリを移動しただけで、全く同じものらしい。 weblogs.java.net/blog/kellyohair/archive/2007/12/openjdk_mercuri_7.html フォーラムで出てた。 forums.java.net/jive/thread.jspa?threadID=34125&tstart=0 917 名前：デフォルトの名無しさん mailto:sage [2007/12/11(火) 13:17:01 ] >>905 あれって use-site でというか、static import で use-site extension methods やると 既存の static import 使ってるコードで問題出るかもって話じゃないの？ 918 名前：デフォルトの名無しさん mailto:sage [2007/12/11(火) 13:56:19 ] >>916 ナルホド。開発者の使ってる環境が知りたいな。GUI無しかな？ Teamwareとコマンドラインの体系は似てるし、CUIベースでかな？ それとも開発者は、Netbeans使ってるから最近出てきたMercurialのプラグイン使ってる？ 919 名前：デフォルトの名無しさん mailto:sage [2007/12/21(金) 12:17:34 ] まだ草案レベルにもなってない例外関連のアイデアらしい www.javac.info/Multicatch.html www.javac.info/Rethrown.html multicatchは欲しい。 multicatchがあれば、rethrownはいらないような気もする。 920 名前：デフォルトの名無しさん mailto:sage [2007/12/21(金) 12:32:25 ] "Exception1 | Exception2" って型ができるのかとおもうと、おらわくわくして（ｒｙ 型とか安全なのかな。とりあえず実現できなくはないと思うけど。 921 名前：デフォルトの名無しさん mailto:sage [2007/12/21(金) 12:47:57 ] 基本的には「複数の catch節をくっつける」ってアイデアで 型安全どーするの？ とかの問題は先送りされてるんじゃね？ Exception1 | Exception2 って型も共通の親クラスのメソッドしか 呼べないんじゃないかと思ってる。下手にcatch節以外でも Exception1 | Exception2って型が使いたいとか騒ぐと、 仕様考える連中が面倒になってポシャるんじゃないかなとか思ったり思わなかったり。 っつーか、Rethrown はその辺が面倒になったから出てきたアイデアなんじゃ？ 922 名前：デフォルトの名無しさん mailto:sage [2007/12/21(金) 16:49:50 ] catch(Exception1 | Exception2 ex) { ex.Foo(); } から catch(Exception1 ex) { ex.Foo(); } catch(Exception2 ex) { ex.Foo(); } は機械的に作れるから、まあ何とかなるんじゃない？ 923 名前：デフォルトの名無しさん mailto:sage [2007/12/21(金) 17:24:21 ] 複数の例外型について handler_pc の位置を共通にするようにするんかと思ってた。 VM仕様で handler_pc はユニークにしろ、とかって制約ついてたっけ？ 924 名前：デフォルトの名無しさん mailto:sage [2007/12/23(日) 21:24:10 ] ConcurrentHashMap<CustomKey<Exception, Handler>, Executor<Runnable>> とかすればいいと思うよ。 925 名前：デフォルトの名無しさん mailto:sage [2007/12/29(土) 10:41:26 ] www.infoq.com/jp/news/2007/12/closures-preserving-feel-of-java クロージャ入れるのも一苦労じゃ 926 名前：デフォルトの名無しさん mailto:sage [2007/12/29(土) 11:01:42 ] おれクロージャいらねぇ派だがどうせ新機能入れるなら個人的には多値返却かAda風の型定義がほしいかな。 927 名前：デフォルトの名無しさん mailto:sage [2007/12/29(土) 12:01:37 ] 皆でScalaへGO! 928 名前：デフォルトの名無しさん mailto:sage [2007/12/29(土) 12:28:15 ] そーいや、ム板にscalaスレあったっけ？ 929 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 00:05:55 ] C#3.0さわってみたが進化してるなあ。 lambda関数が int a => return a + 10 みたいな感じでインラインに書けたりと、 スクリプト言語ラブな人は嬉しい機能がどっさり。 思わず浮気しそうになる・・・。 930 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 00:22:31 ] >>929 > lambda関数が int a => return a + 10 みたいな感じでインラインに書けたりと、 これreturn要らないんじゃ？ BGGAのクロージャの構文、セミコロンがついたりつかなかったりで 局所リターン文だったり単なる式文だったりっつーのはバグの原因になりそうな。 ラムダ式っぽく使うならreturn書きたくないってのもわかるんだけど…… その点、C#の構文はよくできてると思う。 931 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 00:55:17 ] その程度ならecma262で十分。 932 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 01:05:59 ] >>930 それだけじゃなくて、C#3.0のラムダ式で int a みたいにパラメタ型を明示する場合はパラメータリストに括弧が必要なはず。 933 名前：デフォルトの名無しさん [2007/12/30(日) 03:15:35 ] >>926 それだとクラスを返しても全く同じだけど、どう違いをみせたいわけ？ 934 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 10:22:01 ] >>933 戻り値のためにクラスをわざわざ定義するのがめんどいんじゃね？ シンタックスシュガーとしてやってくれると、ちょっと便利かもね、と。 935 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 10:52:00 ] >>928 ちょっと前に探したときは見当たらなかった。 936 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 11:09:29 ] JVM系で残っているスレはこれだけだと思う。 Jython、Groovy、JRuby - どれが一番効率的？ pc11.2ch.net/test/read.cgi/tech/1100563765/ Java系スクリプト言語Groovy pc11.2ch.net/test/read.cgi/tech/1080052050/ 落ちないようにJVM系は統一して欲しいなあ。 Scalaは、Javaとの連携除いても、結構いい型システム持っているけど、 単独ではすぐに落ちちゃうと思う。 937 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 16:42:52 ] >>934 同じくタプルとかも賛成なんだけど、どうもそういうのはJavaぽくないみたい。 面倒だしとかじゃ「違う言語で」とかだから、だから「どう違いをみせたいわけ？」って聞いてる。 少なくとも君の要求ていどならわざわざ文法とか複雑にしなくとも、 Object[] func() でこと足りるしｗ 938 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 16:58:01 ] 多値用のGenericsを標準で用意してくれると嬉しいんだけどね。 こっちで用意してもいいけど、それ専用のjarってのもちょっとね。 939 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 18:28:14 ] 前も出たなこの話題w 俺にいわせりゃ多値引数はあるのに多値返却がないのはおかしいんだけどな クロージャとかの方が違う言語でやってほしいよ。javaがシンプルさとかけ離れていく 940 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 18:44:28 ] クロージャって匿名クラスで作るんだろ？ クロージャの生成側のローカル変数は、その時点で固定になるのかな？ 941 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 19:08:51 ] >>940 そのやりかたが2つくらい出てきてどっちにするかまだ決まってなかったんじゃなかったっけ？ 942 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 19:23:38 ] >>769 あたりか。 943 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 19:32:57 ] あら、割と近めにあったのね。すまんこつ。 944 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 19:35:51 ] 可変長引数を多値引数って言うのは初めてみたかも。 945 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 20:18:52 ] 可変長引数のこと言ってたのか。 946 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 20:21:18 ] たぶん。 いや、はじめてみた言葉だから間違ってるかも知らんけど。 947 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 20:32:39 ] すまん今作った＞多値引数 とっさに出てこなかったんだよ 948 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 20:39:13 ] オーバーロードのことじゃなくて？ 949 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 20:44:29 ] 単純に引数を複数渡せるってだけの話だろ 950 名前：デフォルトの名無しさん mailto:sage [2008/01/01(火) 03:36:41 ] >>949が正解だろ。 単純に引数(インプット)には複数の値を渡せるのに、 返値(アウトプット)が一つしか返せないのはおかしい、という話。 そもそも、大元の関数型言語が(厳密には違うが)一入力一出力だったのを、 手続き型言語で使いやすいよう多入力にしたのが原因。 OOPの思想が確立したときに多出力にすればよかったのだが、折しもCベースのC++が主流だったのでそのまま。 またCPUの最適化の関係もあり、ずるずるとJava, C#・・・と今に至る。 もしJavaで多出力をサポートするなら、 rubyやpythonの返値の扱い（タプル関連)で、シンタックスシュガーが複雑になりすぎてる感があるので、(特にruby) Javaが簡潔かつわかりやすい書式（もしくはタプルに代わる概念)を策定して欲しい、と思う。 951 名前：デフォルトの名無しさん mailto:sage [2008/01/01(火) 10:04:29 ] 単純に引数1個に制限すれば、対称になって>>950の気は済むってこと？ 952 名前：デフォルトの名無しさん mailto:sage [2008/01/01(火) 13:43:46 ] もはや return は継続の呼び出しで良くね？ 953 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 13:56:26 ] ＞Javaが簡潔かつわかりやすい書式（もしくはタプルに代わる概念)を策定して欲しい、と思う。 結局それかよ。それを策定するのが難しいからないんだろ！ おまえが考えて提案したらどうだ？当然英語はできるよな？ 面倒って言うのが理由なら、あまり期待しないほうがいいじゃないか。 それと>>950はツッコミどころが多すぎだけど、 JavaはC++辺りと違って理念が実稼動重視（現実的)だから。 >>951もいいと思うよ。でも Object[] func(Object[]); で十分。JDK1.0 OK 有用であるが、使うかどうかは任意。 954 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 14:05:23 ] >>953書いて思ったけど、 というか普通にポインタ(C, C++)理解してるかってことに行き着くと思うよ。 本質的には、ポインタとかデータ構造とかそういうところ。 955 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 16:52:28 ] ポインタ関係ないな。 参照でいい。 956 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 17:21:18 ] It is assumed that many value return was realized by JAVA and on earth wants to do what? 957 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 19:02:07 ] 新年早々とんだ釣りだw 958 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 19:15:55 ] そうするに偉そうなこといってる>>953はようやくポインタを理解したガキだってこと？ Object[]で戻していいが型の安全を言語側で保証できたらいいねって話なんだが 959 名前：デフォルトの名無しさん [2008/01/02(水) 19:33:42 ] >>958 痛いおまえはｗｗ晒しあげｗｗ 960 名前：デフォルトの名無しさん [2008/01/02(水) 19:42:24 ] また宗教ですか？ 961 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 19:49:45 ] >>958 当然英語はできるよな？ 962 名前：958 mailto:sage [2008/01/02(水) 19:59:22 ] おいおいなんだこれ('A`) >JavaはC++辺りと違って理念が実稼動重視（現実的)だから。 >というか普通にポインタ(C, C++)理解してるかってことに行き着くと思うよ。 こういうのはスルーして俺に総ツッコミかよw 963 名前：デフォルトの名無しさん [2008/01/02(水) 20:00:23 ] ストールマンのお友達ですか？ 964 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 20:03:50 ] >>958 >>962 英語は当然できるんですか？ 965 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 22:57:58 ] 953 名前：デフォルトの名無しさん[sage] 投稿日：2008/01/02(水) 13:56:26 ＞Javaが簡潔かつわかりやすい書式（もしくはタプルに代わる概念)を策定して欲しい、と思う。 結局それかよ。それを策定するのが難しいからないんだろ！ おまえが考えて提案したらどうだ？当然英語はできるよな？ 961 名前：デフォルトの名無しさん[sage] 投稿日：2008/01/02(水) 19:49:45 >>958 当然英語はできるよな？ 964 名前：デフォルトの名無しさん[sage] 投稿日：2008/01/02(水) 20:03:50 >>958 >>962 英語は当然できるんですか？ >>953が何を言ってるのかはさっぱりわからんが、他人の英語の能力に並々ならぬ関心があることだけはわかった。 966 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 23:04:05 ] >>953 > それと>>950はツッコミどころが多すぎだけど、 > JavaはC++辺りと違って理念が実稼動重視（現実的)だから。 C言語のソースがそのままコンパイルできるC++を差し置いてJavaのどこが”実稼働重視(現実的)”なんだww もしかしてC++をまったくさわったことがないんだろうか？ それと>>950のツッコミどころとやらを説明よろしくww 967 名前：958 mailto:sage [2008/01/02(水) 23:23:15 ] ああそういう話ね >>613で出てるけどbugs.sun.com/bugdatabase/view_bug.do?bug_id=4222792で多値はwill not be fixedになってるのよ で、その理由がjavaはシンプルであるべきだーと。 当然コメントには ジェネリクスも加わったし昔のシンプルなjavaじゃないじゃん、とか 配列のシンタクスシュガーならJVMに変更いらないだろ、とか 可変引数があるのに戻り値が複数取れないのはおかしい、とかもうすでに散々出てるわけよ。 でそれを踏まえた上での>>939(俺)の ＞クロージャとかの方が違う言語でやってほしいよ。javaがシンプルさとかけ離れていく だったわけよ 英語が堪能な>>953はそれを踏まえた上で >結局それかよ。それを策定するのが難しいからないんだろ！ >おまえが考えて提案したらどうだ？当然英語はできるよな？ と言ってるんだよな？（>>950は俺じゃねーけど） 968 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 00:35:05 ] 他でやれよもう。 969 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 01:59:17 ] 苦労じゃのう 970 名前：デフォルトの名無しさん [2008/01/03(木) 06:43:34 ] ストールマンじゃないです。 ゴズリンと友達です。 971 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 06:48:51 ] 英語で会話できるようになるのは、日本人の夢なのです！ ジーニアス、ジーニアス！ 972 名前：デフォルトの名無しさん [2008/01/03(木) 06:51:34 ] >>966を読んでみても、相当痛いやつだなということだけは分かるw 30台は間違えないねｗ この様子ならすぐ1000行くけど？どうする？やっちゃう？ 973 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 07:30:05 ] >>962 >>966 おまえに勝ち目はないなｗ そろそろ目を覚ませよｗ 974 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 07:40:36 ] 馬鹿の方が声がでかいのは、ゴミ溜めではよくあること。 975 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 09:02:58 ] それをどうするかが問題なんじゃないか？ 976 名前：デフォルトの名無しさん [2008/01/03(木) 10:55:17 ] また宗教ですか？ 977 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 11:32:48 ] 英語は出来て当然です。 978 名前：958 mailto:sage [2008/01/03(木) 12:24:52 ] ごめんなさい勝ち目はありませんでした。 今目を覚ましました。 979 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 12:30:35 ] 次スレ [Java SE 7] 次世代Javaの動向 6 [dolphin] pc11.2ch.net/test/read.cgi/tech/1199330977/ 980 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 12:43:57 ] 「間違いない」を「間違えない」と書くやつがまだいるのか どこの方言だ？ 981 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 15:46:40 ] >>978 早ｗ 982 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 15:57:34 ] 英語は出来て当然です。 983 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 15:58:57 ] 今目ってなに？ 984 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 15:59:01 ] 技術書の英語は読みやすいからな 詩を書けと言うと無理だが 985 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 16:08:34 ] 英語って読むだけじゃなくて書けないとダメなんじゃないか？おじさん英語じゃあるまいしw 986 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 19:00:42 ] >>984 Full in care, car was to became miss note. 987 名前：デフォルトの名無しさん mailto:sage [2008/01/05(土) 01:02:20 ] This if a pen. 988 名前：デフォルトの名無しさん mailto:sage [2008/01/05(土) 01:54:33 ] >>986 To be,To be,Ten made To be 989 名前：デフォルトの名無しさん mailto:sage [2008/01/05(土) 16:28:25 ] エリート狂想曲ﾅﾂｶｼｽ 990 名前：デフォルトの名無しさん mailto:sage [2008/01/06(日) 10:35:13 ] てｓｔ 991 名前：デフォルトの名無しさん mailto:sage [2008/01/06(日) 23:36:15 ] あれで夢精を覚えた

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef