07/08/21 18:15:12
Calendarいらないってがんばっている人もいる。
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(d.hatena.ne.jp)
これが本当に通ってくれれば
憂いなしで嬉しいな。
332:デフォルトの名無しさん
07/08/21 18:29:39
つか、きしださんまで月間違ってるし！
333:デフォルトの名無しさん
07/08/21 19:05:53
>>330
ラッパークラスで解決しようというのはダメだろ。
Calendar の set やら get を ラップして 1月が1になるようにしても、
自分の目の届く範囲だけなら構わないけど、
第三者が作ったクラスに渡す場合には、そのまま渡したら 1ヶ月ずれる。
そんなゴミをコアAPIに入れられたら、 Calendar をやり取りする
メソッド作る場合に、必ず instanceof とかでチェックしなきゃいけなくなる。
334:デフォルトの名無しさん
07/08/21 19:08:21
>>331
無理じゃね？
java.util.Date は Serializeable だし、
Date の TimeZone対応とかやったら、
シリアライズされたデータの互換性なくなるんじゃないか？
335:デフォルトの名無しさん
07/08/21 19:10:30
W3C-DateTimeからRFC2822-DateTimeに用意に変換できるようなものが欲しい。
RFCのほうはCWFSのおかげでやたらパースがしにくい。
336:デフォルトの名無しさん
07/08/21 19:23:34
>>330
> これだけJavaが使われてその問題点が明らかになったんだから
> 新しくより合理的なAPIができてもいいと思う。
あっても良いけど、closure とかに比べると優先度は低いよね。
それに「問題点」ってのも個人個人で違うわけで、1月 が 0 なのがダメなのか、
setter の戻り値の型が void だから、1行に詰め込んで書けないのが問題なのか
それ以外なのか。
現状では愚痴とか不満は出てるけど、
それらを一つに纏めて、多くの人が納得でき、多くの人が幸せになれるような
解決策が提示されているかっていうと、少なくとも JSR-310 は違うと思う。
337:デフォルトの名無しさん
07/08/21 20:22:16
>>335
まえにjavascriptの実装がどっかのブログで公開されてたぞｗ
338:デフォルトの名無しさん
07/08/21 22:16:24
>>336
いや、JSR-310はまだ固まってないし。
そういう動きがある、ということしか言えないと思う。
なんで、これからの頑張り次第でしょ、という話。
それとも、「日付関係の新しいAPIは要らないぜ」という話？
339:デフォルトの名無しさん
07/08/21 23:24:14
>>338
1月が 1 と書けるようになっただけ、の Calendar みたいなクラス作られても
あっちのフレームワークでは互換性のために旧Calendar要求され、
こっちのフレームワークでは機能性のために新API要求され、
みたいに手間が増えるだけになる可能性が高い。
かと言って、Calendar が解決しなかったニッチな要求のためだけのAPI作ったら
わざわざ標準APIに突っ込む必要ないって話にもなるし。
既存のDate＆Calendarがある状況で
日付関係の新しいAPIを作るのは凄く難しいと思ってるんだけど、
1月が 0 なのがキモイみたいな事かかれると、
マトモなものが出来るのか心配になるって話。
340:デフォルトの名無しさん
07/08/21 23:27:03
動画再生用のSwingコンポーネントが標準化されたりしたら嬉しいのだけど、
JavaFX Scriptに合わせて対応してくれたりせんのかねぇ。
Flashは次のバージョンでH.264にも対応するとか発表してるし、
本気でRIA市場に乗り込むならここらへんを抑えてくれないと支持しにくい。
341:デフォルトの名無しさん
07/08/21 23:36:53
つ JMF
342:デフォルトの名無しさん
07/08/21 23:38:58
JRE以外にインスコしてもらえるわけないじゃんｗ
343:デフォルトの名無しさん
07/08/21 23:51:58
jarに全部突っ込んでマニフェストでパス指定するか。JWSでいいだろ。
けどJMFのH.264コーデックがまだIBMのプロプラライセンスものしかなかった気がする。
344:デフォルトの名無しさん
07/08/22 09:04:57
>>339
相互変換はコンストラクタ一発なんだから問題ないんじゃね？
345:デフォルトの名無しさん
07/08/22 09:09:49
SilverlightやFlashに比べて、JREはインストール面で不利すぎる気がするのですが
軽量プラグインとか出す予定はないのでしょうか？
346:デフォルトの名無しさん
07/08/22 09:24:14
何を削るかで揉める事必至だろうなぁ・・・
いっそのことJ2MEのランタイムを作ってそれを軽量プラグインにするとか
347:デフォルトの名無しさん
07/08/22 11:31:10
分割ロードの方が良さそうだなあ。
Javascriptは何でも一つのファイルにぶち込むのが流行ってきているけれども。
348:デフォルトの名無しさん
07/08/22 14:09:41
>>345
Java Kernel と呼ばれているものを jdk6 update 4 で出す予定
URLﾘﾝｸ(weblogs.java.net)
URLﾘﾝｸ(weblogs.java.net)
349:デフォルトの名無しさん
07/08/22 14:24:44
>>344
Date と Calendar はコンストラクタ一発で変換できてないじゃん。
それと同じ事が起こる事は十分予測可能。
350:デフォルトの名無しさん
07/08/22 14:30:23
>>349
っつーか、コンストラクタ一発で変換できても煩雑なのは変わらんのだがな。
351:デフォルトの名無しさん
07/08/22 20:01:17
”よく知られた日付型”がこれ以上混在されてもうざいだけだよ。
DateにCalendarにsql.Dateと、”よく知られた日付型”は、もう既に食傷気味です。
所詮は64bit unix epocと割り切ったユーティリティメソッドが拡充される方がよほど嬉しい。
352:デフォルトの名無しさん
07/08/22 21:21:02
なるほど。
良くあるパターンに特化したユーティリティメソッドを用意してくれる方が
ありがたい気がする。
353:デフォルトの名無しさん
07/08/22 21:49:03
JREのインスコなんてウィザードに従えば良いだけだろ。
それより、システム管理全体がside by sideへ以降してきてメンテにエンドユーザーの負担が掛かってると思う。
354:デフォルトの名無しさん
07/08/23 01:19:58
JSR 310はいいと思う。
ユーティリティ・クラスとしても上出来。
355:デフォルトの名無しさん
07/08/23 03:08:43
>>354
そうなん？
>>310 に JSR-310 のAPIリファ来てるけど、
これどんな時に便利なのかサンプルコードとか書いてくれん？
っつか、オレには Moment や Period のサブクラスが
年、月、日、時、分、秒と分かれてる必要性がイマイチわからん。
356:デフォルトの名無しさん
07/08/23 04:03:13
タイムベースの処理が必要でそのフレームワークを自前で作らなきゃいけないときに下のライブラリとして使えそうだな。
357:デフォルトの名無しさん
07/08/23 04:06:51
>>310がJSR-310のリンクになっていることに
今になってようやく気が付いた。
なんか黄色ナンバーの車を1日10台見たとか
ワーゲン見たとかその程度にちょっと幸せ。
358:デフォルトの名無しさん
07/08/23 08:11:21
>>355
ぶっちゃけ、>>310より>>331の方が良いと思う……
359:デフォルトの名無しさん
07/08/23 08:43:24
>>356
逆に言うと、それ以外の目的に使えなさそうじゃね？
360:デフォルトの名無しさん
07/08/23 08:46:22
どっちがいいとかそういうもんじゃないだろ。
310はベースとなる時刻クラスを提供するんだから。
361:デフォルトの名無しさん
07/08/23 08:49:25
今のままだったら Date ＆ Calendar の方が下位層で
JSR-310 はそれに乗っかるだけの上位層になりそうだが
362:デフォルトの名無しさん
07/08/23 08:50:20
（ ﾟдﾟ）ﾎﾟｶｰﾝ
363:デフォルトの名無しさん
07/08/23 08:52:26
おまけに使用用途が酷く限定されている、と。
364:デフォルトの名無しさん
07/08/23 09:01:34
>>360
んじゃ言い直そう。
JSR-310 のスライドにあがってる、
What is wrong with Date and Calendar?
の解決策としては、今のところ>>331の方が良さそうに見える。Date の
Could not be successfully localized とか Most methods deprecated、
SimpleDateFormat の Calendar cannot be directly formatted
は解決できそうだ。
365:デフォルトの名無しさん
07/08/23 09:25:39
>>360
310が提供するベースとなる時刻クラスってどれよ？
366:デフォルトの名無しさん
07/08/23 11:36:39
文字列からのファクトリメソッドは、
別クラスにした方がいいんじゃないの？
L10N考えると劇重プロジェクトだし。
GNU dateコマンドみたいな時間指示を考えると、やること一杯ある。
367:デフォルトの名無しさん
07/08/23 11:46:17
これはひどい
ベースとなる時刻クラス・・・ Instant かねぇ
でも CalendarDay や TimeOfDay との相互変換はできそうになく
既存の Date や Calendar との繋がりもない
どうやって使うんだこれ
368:デフォルトの名無しさん
07/08/24 00:25:02
310はまだ、かなりドラフトな感じだが、
PeriodとMomentとその実装クラスを細かく分けるのは、
安全でかつ読みやすくなるのでよいと思う
例えばMomentにMomentは追加できないがPeriodは追加できるとか
369:デフォルトの名無しさん
07/08/24 01:23:17
Instant と fully defined な SingleMoment を区別する理由と、
Period と Interval を区別する必要とか、
Duration とか良く分からん。
Duration と Inteval はまだ出来てないみたいだけど。
>>368 も同意っちゃ同意なんだけど、
それって Moment と Period が別になってる理由にはなっても、
Moment や Period のサブクラスが 年、月、日、時、分、秒と
細かく分かれてる理由にはならんよね。
370:デフォルトの名無しさん
07/08/24 01:58:25
>> 369
>Moment や Period のサブクラスが 年、月、日、時、分、秒と
>細かく分かれてる理由にはならんよね。
なんで?
Days days = ...;
days = days.plus(Days.days(3));
とか具体的な型が決まっていたら安全かつ読みやすいじゃん。
しかしメーリングリストだとなんかいろいろ提案とか出されたり、まだまだな感じがしてきた。
sunの中の人が書いてるが、
URLﾘﾝｸ(blogs.sun.com)
既存のAPIとの互換性とか国際化も考えると大変そうだね。
371:デフォルトの名無しさん
07/08/24 02:02:32
>>369
後者については type safe のためとか？
もしくは、
Moment moment = build(dayOfMonth(1), hourOfDay(3));
とかやると、毎月 1日午前 3時 をあらわすようになるとか……
372:デフォルトの名無しさん
07/08/24 02:05:26
>>370
おいおい……
一見型安全かもしれないけど、
それだけだと、逆に Period で 1カ月と3日とか複合的な指定できなくなるんですけど……
373:デフォルトの名無しさん
07/08/24 02:10:03
>>371
あぁなるほど。可変長引数のビルダーメソッドで纏めるとか
そーゆー場合には別々のクラスになってないとダメだな。
>>370
これはひどい
374:デフォルトの名無しさん
07/08/24 02:34:16
>>372
Periodとしての一ヶ月というのは日数として組み合わせて扱えない気がするが。
375:デフォルトの名無しさん
07/08/24 02:37:46
（ ﾟдﾟ）ﾎﾟｶｰﾝ
376:374
07/08/24 02:48:29
今のAPIを見る限り、複数のPeriodを組み合わせたPeriodというのはない気がする。
Monthsに関しては月によって日数は変わるので、months.plus(Days.days(3))みたいな計算は書けないと思うが。
しかしCalendarDayはplus(Period...)というのを持ってるので、一ヶ月と3日後とかを計算できると思う。ただMinutesとSecondsとの変換とかできそうな気がするのにできないように見えるのはよくわからない。
377:デフォルトの名無しさん
07/08/24 02:51:08
>>372
そーゆーのは、まだない Interval でやるって話なんじゃね？
しっかし、凄く分かりにくい API だな、これ。
そこそこ経験がある奴でもサンプルコードが無いと一行も書けないぞ。
378:デフォルトの名無しさん
07/08/24 02:55:09
>>373
instanceof で比較するところを enum と switch で置き換えれば
良いだけだから、別々のクラスになってる必要は全くなかったりする。
379:374
07/08/24 03:03:40
やっぱりわかりにくいのだろうか?
変換とかファクトリとかのメソッドがどこにあるかわからず、分かりにくい、というのはあるかもしれないが、
そもそも日付と時間の長さなどを区別して扱うこと自体が複雑で、結局intとかで扱っても値の種類を把握していないといけないのでは。
ある程度、単位を型でエンコードして分かりやすくすることで安全で読みやすいコードになる方がよいと思うのだが...
380:デフォルトの名無しさん
07/08/24 05:59:11
Sun が NASDAQ での銘柄記号を SUNW から JAVA にかえるんだそうな。
URLﾘﾝｸ(blogs.sun.com)
URLﾘﾝｸ(blogs.sun.com)
いや、次世代Javaと関係ないけど。
っつーか、これジョークじゃないの？ 4月1日じゃないけどさ。
381:デフォルトの名無しさん
07/08/24 07:09:27
Dateみたいな基本的なところに今から手を入れるのがアリなら、
Numberもどうにかしてくれんかな。
やっぱり Integer inherits Double であってほしいし、BigDecimalで
持っている四則演算メソッドはNumberすべてで使いたいが。
382:デフォルトの名無しさん
07/08/24 07:17:34
>>380
JAVAの株があがったとか下がったとかが問題になってくるわけか。
そしたら、JAVAと大文字で書くやつはJavaのことを知らないという伝説が強くなるわけだ。
383:デフォルトの名無しさん
07/08/24 07:43:01
>>381
Numerics関係は難しいんだよな、後からいじるの。
非互換の影響が大きすぎて。
仕様お目付け役だった、Guy Steeleさん、この辺が弱い。
384:デフォルトの名無しさん
07/08/24 16:04:46
元がSUNWならJAVAWにすればいいのにコンソール出ないし・・・。
385:デフォルトの名無しさん
07/08/24 16:57:17
>>381
メソッド追加はありでも継承関係は変えられないだろうな
386:デフォルトの名無しさん
07/08/29 21:26:22
そろそろ deprecated のクラスやメソッドを一掃してほしい
387:デフォルトの名無しさん
07/08/29 22:30:24
Cloneable を Clonable に直してほしい
388:デフォルトの名無しさん
07/08/30 02:13:33
creat....
389:デフォルトの名無しさん
07/08/30 23:47:25
catch必須例外を堂々と無視できるプラグマを追加してほしい。
390:デフォルトの名無しさん
07/08/31 03:25:48
アホか例外処理の意味ないだろ。
握り潰すことすら面倒くさいか？ｗ
391:デフォルトの名無しさん
07/08/31 12:32:21
JDK7 build19
URLﾘﾝｸ(www.java.net)
URLﾘﾝｸ(download.java.net)
forumで話題になっていた
4811096 Allow mixing of heavy and lightweight components
が入った様子。
SwingとAWT混ぜるなっていうのが古い話になるわけだ。
あと、レポジトリ管理、Teamwareを完全撤廃？SCCSキーワードの削除ってのが結構あった。
公開してるのも、Subversionでだしね。OpenSolarisで採用してる、Mercurialはないんだろうか？
392:デフォルトの名無しさん
07/08/31 21:15:56
>>390
めんどくさい。
どうでもいいコンソールプログラム書くときは
全部例外がトップレベルに流れて死んでくれていい。
あと、どうせならインタフェースの実装も堂々と無視できるプラグマも欲しい。
適当にnullとか0とかfalseとか、あるいはNotImplementedException投げるとか。
IDEにやらせればいいんだけどさ。
393:デフォルトの名無しさん
07/08/31 21:52:53
>>392
お前はCの方が合ってるんじゃないか？
つーかその程度の捨てアプリならスクリプトで実装すれば良いだけじゃん。
394:デフォルトの名無しさん
07/08/31 22:32:46
mainメソッドにthrows ExceptionってすればOK
395:デフォルトの名無しさん
07/09/01 02:07:00
Javaの例外処理の面倒くささはMatzがどっかで言及してたね
396:デフォルトの名無しさん
07/09/01 02:21:10
silentClose(Closeable) みたいなメソッド作るとか
使い捨てアプリ作る時は throws Exception つけるとかすれば
そこそこ改善すると思うんだけどね
397:デフォルトの名無しさん
07/09/01 02:29:38
>>395
むしろその例外処理の面倒さがないからこそ
他の言語があぶなっかしくて使えない。
コード品質重視だと特に。
398:デフォルトの名無しさん
07/09/01 06:37:06
むしろ投げる例外をdoc,code上で明文化されてないと何拾って良いか分からないだろ。拾えないと例外に対処できない。
throw,throwsでthrowable以外が飛んでくるのもおかしいし。
399:デフォルトの名無しさん
07/09/01 16:45:03
ExceptionはThrowableである。以上。
400:デフォルトの名無しさん
07/09/02 09:52:45
例外処理の仕組みが問題というよりも
IOExceptionとかSQLExceptionのようなレベルの例外を
チェック例外にしてるのが問題だと思う
SpringやS2やHibernateなら、これらの例外をランタイム例外にラップしてくれるし
JavaEE5ではランタイム例外を多用してるけど
肝心の、JavaSEのコアなAPIがチェック例外だらけだからな
>>397
現実には、Javaのチェック例外記述のめんどくささに嫌気がさした開発者が
catch (Exception e) {
e.printStackTrace();
}
とか書いて、返って品質悪化するパターンの方が高い気がするorz
401:デフォルトの名無しさん
07/09/02 11:41:41
あと InterruptedException も握りつぶされて困りやすいチェック例外だ
あー
InterruptedIOException とか、きっと知らんうちに IOException もろとも握りつぶしてる気がしてきた
try {
......
} catch (InterruptedIOException e) {
Thread.currentThread.interrupt();
} catch (IOException e) {
......
}
なんて、書いた覚えがないよ
402:デフォルトの名無しさん
07/09/02 11:50:49
例外のためのEffective Javaみたいなのがあれば読んでみたい。
こういうのはお習字の世界だから仕様としてどうこう変えるもんでもないし。
403:デフォルトの名無しさん
07/09/02 13:29:09
>>400
IOExcepotionとかは>>396みたいなメソッドがあれば解決する問題
後半に関して言えば
そーゆー奴は面倒くさいので例外処理しないし
他人のために必要な例外関連のドキュメントも書かない
ので検査例外をあってもなくてもそれほど品質は変化しないと思うが
404:デフォルトの名無しさん
07/09/02 13:39:45
何が言いたいのやら・・・必死なことだけは解るが
405:デフォルトの名無しさん
07/09/02 13:48:59
IOExceptionやSQLExceptionがチェック例外なのは当然だろ？
外部リソースに依存してんだから、チェックし無い方がどうかしてる。
DAOならそれらをcauseにして、DAOExceptionみたいに新たなチェック例外にくるむがよろし。
406:デフォルトの名無しさん
07/09/02 13:55:57
closeが例外なげるバカなAPI
407:デフォルトの名無しさん
07/09/02 14:04:03
close は flush を伴うからエラーが発生する可能性はある
408:デフォルトの名無しさん
07/09/02 14:07:19
closeが例外なげるのがバカってどんだけゆとり脳なんだ
409:デフォルトの名無しさん
07/09/02 14:14:18
思うに、チェック例外をキャッチしないと
警告出すだけの仕様だったらどうなっていただろうか？
410:デフォルトの名無しさん
07/09/02 14:26:33
throws SQLException って書いてないのに throw new SQLException() するような
混ぜるな危険メソッドが書き放題で検査例外の意味がなくなる。
それでいてソースに SuppressWarnings("ignorecheckedexception") とか
コンパイル時に -ignorecheckedexception とか必須だと手間がかかるだけ。
中途半端で役に立たないソリューションの見本だな。
411:デフォルトの名無しさん
07/09/02 14:30:17
んなもんソースレビューで片付けろよ
412:デフォルトの名無しさん
07/09/02 14:44:28
closeが検査例外を投げるバカなAPI
413:デフォルトの名無しさん
07/09/02 14:49:51
>>411
第三者の作ったライブラリやフレームワーク使う時は
それらも全部ソースレビューすんの？
414:デフォルトの名無しさん
07/09/02 14:51:10
必ずソースが見れるとは限らんし
415:デフォルトの名無しさん
07/09/02 15:05:42
>>405
IOExceptionとかって多くの場合リカバリできるの?
リソースの解放はfinallyでやるからチェック付き例外とは関係ないと思うし
なるべく例外がチェックできるべきだという意見は多い様に見えるが、一般的にそれらの例外がほとんどリカバリできる処理を書けないならば >>400の言うようにAPIの設計の問題では?
416:デフォルトの名無しさん
07/09/02 15:10:27
ソケット使って読み書きしてる時にIOExceptionが発生したらリトライするとかあるよね
417:デフォルトの名無しさん
07/09/02 15:53:29
>>416
そういう特定の事情のために、すべてのIO処理で面倒なコードを書かないといけないのはアホ
418:デフォルトの名無しさん
07/09/02 15:56:09
というか、例外が出ないコードで例外の補足が必要になるのが、設計ミス
System.in.read()
とか
419:デフォルトの名無しさん
07/09/02 15:57:17
面倒っても、throws IOException を宣言するくらいのもの。
その場で対処しない例外は上へ送る。
420:デフォルトの名無しさん
07/09/02 16:02:53
System.in.read() ってプラットフォーム側の標準入出力の実装方法によっては
例外が出る可能性があるんだが
421:デフォルトの名無しさん
07/09/02 16:10:33
俺としてはNumberFormatExceptionが実行時例外なのが許せないくらいなんだが。
外側のことは一切信用しないという性悪説プログラミングが心情だとね。
422:デフォルトの名無しさん
07/09/02 16:18:48
俺はUserTransactionのメソッドを使ってみたとき、
Javaのチェック例外は、API側が使い方を根本的に間違ってると痛感したよｗ
423:デフォルトの名無しさん
07/09/02 16:24:01
>>412みたいな事を言う奴から間違ってると言われても
424:デフォルトの名無しさん
07/09/02 16:31:07
>>419
それで上へ送った例外は結局どうなるわけ?
throws IOExceptionをまき散らして、
RuntimeExceptionになるか握りつぶされるぐらいじゃないの?
>>421
一切信用しないというのはいいが、それはどうやって処理される?
他の値で代用するのは多くの場合問題がある気がするし、
再度入力を促すことになると思うが、
可能な場合と不可能な場合(処理を中断するしかない場合)があると思う
...NumberFormatExceptionに関しては微妙な気がしてきた
RuntimeExceptionでよい場合も多いと思うが...
425:デフォルトの名無しさん
07/09/02 16:54:22
最近じゃ例外もAOPで処理するし、リソースはfinallyで閉じるからあまり関係ないしな
matz氏がブログで、例外をぎりぎりまで捕捉しないのがRuby流って書いてたけど
結局はそれがいちばん効率的で、開発者に都度catch処理を強制するよりも品質が上がるんだよね。
例外処理がなくても、異常終了で落ちるからテスト時にすぐわかるが、
catchで不用意に握りつぶされた例外はやっかいだし
426:デフォルトの名無しさん
07/09/02 17:06:07
何層か下のフレームワーク/ライブラリが投げてくる実装依存の例外もやっかいだけどな。
面倒くさいから検査例外は無い方が良いとか考えてる奴は、
例外関連のドキュメントなんて書かないから品質ズタボロのコードを量産する。
427:424
07/09/02 17:27:46
>>425
アプリケーション(基本的なライブラリでない)でのチェック付き例外は有用と見られているはずだ
アプリケーションレベルではリカバするべき例外を決めることができて、チェック付き例外で強制できる
アスペクトを使うことでIO例外をアプリの例外へ変換とかはうまく書けるが、
各メソッドごとの例外処理を常にうまく分離して書けるわけではない
テスト時にすぐわかるというのは理由にならないはずだ
再現が難しい例外だってあるから
それよりも発生したときなにもできないことが多いというのが理由だと思う
428:デフォルトの名無しさん
07/09/02 17:28:11
なんか次世代関係なくなってね？
JAVAの例外について勉強するスレとかたててそっちでやれ
429:デフォルトの名無しさん
07/09/02 18:30:35
例外処理が煩わしいのであれば、
例外処理を包含したテンプレートパターンを適用して処理すればいい。
APIは面倒か面倒じゃないかではなく、安全か安全ではないかが重要。
APIは極力安全に使えるように「馬鹿向け」に作られているが、
本当の馬鹿にはその意味すらわからないらしいｗ
430:デフォルトの名無しさん
07/09/02 18:57:24
わずらわしいどうの以前にその例外をどう扱うべきかというパターン自体が俺みたいな初心者にはわからない
使われる側でチェック例外を投げてから使う側で遺言を言ったあとRuntimeExceptionでラップするとか、
キャンセルなどの特殊な状況を処理するために使うとか、なんだろうか
431:デフォルトの名無しさん
07/09/02 21:40:59
捕捉する場所によって扱い方も異なるとしか言い様がないな。
ライブラリ書いてるなら、抽象的な例外でラップして投げなおすだろうし。
フレームワークならコントローラで一括処理で、それ以外では全部投げっぱなし。
432:デフォルトの名無しさん
07/09/02 21:49:00
個人的にはチェック例外＝病気の診断、ランタイム例外＝安楽死とか思ってる
で、今直せる見込みのない病人がいるとして、いろんな病院をたらいまわしたり（チェック例外のままthrowsしまくる）、
病気ではないとして放置したり（例外を握りつぶす）、
秘密裏に抹殺したり（System.exit(0)）、
するよりはランタイム例外にして安楽死させたほうがいいような気はするんだけどな。
でもそのあたりの常識やパターンやガイドラインみたいなものがないと実際何をやっていいのか分からないし、
URLﾘﾝｸ(www-06.ibm.com)とか見る限り、
今のAPI仕様でそれが完璧に行われているかというとそうでもない気がする。
どう診断すればいい医者であるか、と言う問題についてはもっと語られてもいい気がする。
433:デフォルトの名無しさん
07/09/03 00:54:17
病気になったら即安楽死＝良い医者だと？
434:デフォルトの名無しさん
07/09/03 00:56:05
スレ誘導しようとしたらいつのまにか例外処理スレが落ちてた。
435:デフォルトの名無しさん
07/09/03 04:46:11
>>420
その程度ならRuntimeExceptionで十分
436:デフォルトの名無しさん
07/09/03 07:58:03
>>435
その程度なら throws IOException 書いておけば十分。の間違いじゃね？
437:デフォルトの名無しさん
07/09/03 08:17:25
>>435
もっかい URLﾘﾝｸ(www-06.ibm.com) 読んでくれば？
438:デフォルトの名無しさん
07/09/03 08:53:56
>>432
ロッド＝ジョンソンの本の説明が出てるな
自分も彼のJ2EE本読んで、チェック例外に対する見方を改めた口だ
439:デフォルトの名無しさん
07/09/04 11:17:45
例外処理がもれなくSystem.exit(0)オンリーなソースを
押し付けられた俺涙目
440:デフォルトの名無しさん
07/09/04 11:21:35
例外処理が全部 System#exit(int) ってのもアレだが、
異常終了してんのに 0戻すってのも相当アレだよな。
441:デフォルトの名無しさん
07/09/04 11:36:48
終了するというコードが正しく実行できたので正常！
と。
曲がった先の信号が青だから曲がれる、という理屈に似てます。
>>439
まあ握りつぶされるよりはいいんじゃないか？
例外処理に関しては、パッケージ単位とか、今度出来るはずのモジュール単位で
包括して処理できる仕組みがあったら便利じゃないかなぁと思う。
442:デフォルトの名無しさん
07/09/04 14:31:16
>曲がった先の信号が青だから曲がれる、という理屈
これめちゃくちゃ危ないんだが・・・特に内輪差考えないで突っ込んで来る馬鹿な大型車とか。
443:デフォルトの名無しさん
07/09/04 22:43:55
>>439
脈絡ないけど、exit()の前にfree()は要らないってのを思い出してしまった。
444:デフォルトの名無しさん
07/09/04 23:43:03
>>432
一理あると思うが、マルチスレッドの場合はランタイム例外もきちんと
捕捉しとかないと握りつぶしたのとたいして変わらないことになるんだよな。
そのへん整合性あるガイドラインならいいんだが。
あと、安楽死というからには本当はやっぱり後始末もちゃんとしておきたいところ。
445:デフォルトの名無しさん
07/09/05 14:32:56
あのfree論争ってさ、
「とりあえずfreeはしておくべき」的な教条的理想論
「どうせ終了と同時にメモリ開放するんだからいいじゃん、っていうかfreeしたって実際何もしてないのとほぼ同じだし」っていう感じの現実論
って理解でいいんだよな？そりゃ永遠に話は平行線だ罠
446:デフォルトの名無しさん
07/09/05 14:37:30
例外ってさ、単純な入力ミスで出るようなはっきりいって例外処理までしてやりたくないようなどうでもいい例外か
出てる時点でもうもうどうしようもない例外が多いような気がする
447:デフォルトの名無しさん
07/09/05 15:06:10
外部からの入力ミスなら対処しないとダメだろ。
使い捨てアプリ作ってんなら、throws Exception 付けといて良いだろうし。
448:デフォルトの名無しさん
07/09/05 15:16:29
>>445
マトモな奴は、free論争なんかする暇があったら他の事をやる。
449:デフォルトの名無しさん
07/09/05 15:25:06
>>445
>>448 の2つに直交する「どっちでもええがな」論があって、これが現実解。
450:デフォルトの名無しさん
07/09/05 15:46:51
parseIntで数字じゃなかったときの処理を例外でやんないといけないとか、ひどすぐる。
451:デフォルトの名無しさん
07/09/05 16:05:21
>>450
なら、どうしたら良いと思う？
parseInt の戻り型を long にして数字以外なら int の範囲外が返ってくるとか、
parseInt の戻り型を Integer にして数字以外なら null 返すとかしても、
例外よりマシになるとは思えないけど。
452:デフォルトの名無しさん
07/09/05 16:11:43
＞parseInt の戻り型を Integer にして数字以外なら null 返す
それやるとオートボクシングしたつもりがヌルポになったりすっからなあ
isValidInteger()みたいなチェックメソッドを作ってやるとかどうよ。二度手間だが
453:デフォルトの名無しさん
07/09/05 16:15:34
>>452
安全なコードを書くためにそのメソッド使った
if文を書くことを強制しないといけない。
ならコンパイラでチェックしてやろうというのが
検査例外な訳で。
どこまで人間を信じるかだな。
454:デフォルトの名無しさん
07/09/05 16:15:42
> isValidInteger()みたいなチェックメソッド
なんという銀の弾丸
455:デフォルトの名無しさん
07/09/05 16:18:36
int[] parseInt(String)
返値は
{ パースした数字, エラーコード }
俺もparseIntについては何とかならないかと思ってた。
parseできないってのは、想定内の状況だからExceptionにするのはどうかな、と感じてて
例外と言うより１状況として扱いたいと思ってる。
ただ、上のようにしても何かしっくり来ない。
Exception以外に、例外状況をメソッドの返りで扱えるようになればいいな、と思う。
Exception処理が重すぎるというのが元凶なんだが、
RuntimeExceptionでないものに関しては
parseIntのように、stackTraceなんて重いものは要らなくて、
その場で処理してしまう例外状況って多いじゃないですか。
何とかならないのかなぁ。
言語構造的に、Throwable一本ってのが簡単なのは分かるんだが・・・
456:デフォルトの名無しさん
07/09/05 16:25:02
>>453
＞if文を書くことを強制しないといけない。
ここに関しては
Nullチェックに対するNullPointerException
Iterator#hasNext()に対するNoSuchElementException みたいなRuntimeException派生を投げれば済むと思うんだけど
二度手間なんだよね。このチェック。
457:デフォルトの名無しさん
07/09/05 16:29:35
>>456
hasNextはそのチェック自体が軽いからいいけど
parseIntは、parseしちゃってるからねぇ・・・二度手間ですよねぇ・・・・
458:デフォルトの名無しさん
07/09/05 16:29:50
>>455
> parseIntのように、stackTraceなんて重いものは要らなくて、
> その場で処理してしまう例外状況って多いじゃないですか。
parseInt の場合だと、
・ユーザー入力を parseIntした場合はユーザー入力が遅いのでExceptionが重くても問題ない。
・ファイル読み込んでparseIntした場合、パースできないケースは例外を使うべき状況なので問題ない。
だと思うが。
459:デフォルトの名無しさん
07/09/05 16:33:25
自己レス>>457
あ。parse結果をキャッシュできればいいのか。内部で。
って、コトは、staticメソッドじゃ駄目だな。
Stringのインスタンスメソッドになれば何とかなる、という所か・・・・
460:デフォルトの名無しさん
07/09/05 16:35:35
>>456
要するに、検査例外だと
コードがごちゃーとするのがやだから
実行時例外にして欲しいって事でしょ？
どっちにしろ、人間をどこまで信じるかだな。
461:デフォルトの名無しさん
07/09/05 16:37:04
>>460
paeseInt の話なら、NumberFormatException は実行時例外だが。
462:デフォルトの名無しさん
07/09/05 16:44:43
>>455
最近の言語であるみたいにJavaが多値を返せる言語だったら良かった
んだけどなあと思う。
(int, StatusCode) parseInt(String input)
とか。
ちょっとキモイが
interface ParseResult { }
class ParseSucceed implements ParseResult { }
class ParseFailure implements ParseResult {}
というクラスを用意して、ParseResult型の値を返すとかどうだろう。
463:デフォルトの名無しさん
07/09/05 16:48:13
>>462
後半、ただのEnumでよくね？
464:デフォルトの名無しさん
07/09/05 16:48:49
そんなややこしいことやるくらいなら Integer を返して null かどうかで判定できればそれでいいよ
465:デフォルトの名無しさん
07/09/05 16:52:55
>>464
だからそういうのやるとコードの変なところでヌルポが出そうで怖いんだって
オートボクシングするだけで出るし正体不明のバグ増やすだけ
466:デフォルトの名無しさん
07/09/05 16:56:38
じゃあ @CheckForNull 付加で
467:デフォルトの名無しさん
07/09/05 16:57:55
>>462
StatusCodeチェックしない場合はパースに失敗してても intの値が得られちゃうし、
その上現状よりキモくなってるしで、あんま良い事ないんじゃね？
468:デフォルトの名無しさん
07/09/05 17:02:33
>>462
多値を返すという話はだーいぶ昔からBugParadeでやられてて
話に参加してみたものの結局、やらないよーという結論。
まあ、どうしてもやりたきゃ、今は配列をつかえってところ。
それなら俺は、配列に違う型を含められるようにしてくれ、と思い・・・
でも、その場合型チェックはコンパイル時には難しいわけで
Objectの配列使うのと変わらないわけで・・・・
じゃあ、じゃあstructがあったらいいんじゃ・・・・っていうと、
アレ？それってクラスじゃね？と・・・・
型チェックが緩くてもともと実行時にしか型がきまらない
スクリプト型言語なら、複数返値も考えることあんまり無くていいんだろうけどねぇ
469:デフォルトの名無しさん
07/09/05 17:24:54
>>468
いやいや。型に厳しい関数型言語(MLやHaskell)などでは、
昔からタプルという形で多値が扱えたから、それと同等の
仕様にすればいいだけだと思うんだがな。
470:デフォルトの名無しさん
07/09/05 17:28:34
>>463
実装は省いたけど、ParseSucceed型からはパーズ結果の値を、
ParseFailure型からは失敗の原因を取得できるようにする意図が
あったので、ただのEnumだとよくない
471:デフォルトの名無しさん
07/09/05 17:47:44
>>469
>>455 だと Exception重いからException使わないようにしようって話でしょ。
タプルとか使って正常系の処理も重くしたら意味無いんじゃね？
472:デフォルトの名無しさん
07/09/05 17:55:24
>>470
パフォーマンス上の理由なら、そんなもんいちいちnewして返すぐらいなら、例外投げればいいと思う。
単にコードを簡潔にしたいだけなら、
static boolean parseInteger(String text, AtomicInteger out);
みたいなのをどっかに用意してやればいい。
AtomicIntegerは、他に標準でintを参照渡しできるインターフェイスが無いからなんで、
適当なintをsetできるインターフェイスならなんでもいいと思う。
コードを簡潔にするっていっても、結局正しくパースできたかのチェックは必要なんだから、
例外で十分でしょ。
473:デフォルトの名無しさん
07/09/05 18:06:05
しかし事前チェックが出来ないにもかかわらず実行時例外を投げてよろしいものだろうか
同じく文字列を解析して取得するタイプのClass#forNameが発行するClassNotFoundExceptionはキャッチ例外だよね？
474:デフォルトの名無しさん
07/09/05 20:31:41
>>472
パーズ失敗というのは、自分にとっては正常系の処理なんで
例外使うのは違和感があるんだ。感覚的な問題なんだけど、
Map<K, V>#get(K key)がkeyがエントリに存在しない場合に
例外を投げられると嫌なのと似た理由で。
475:デフォルトの名無しさん
07/09/05 20:35:55
>>474の補足だけど、Mapから値を取得しようとしたときにキーが存在しない場合
というのは、正常系の処理であることが多いから、もしもJavaのAPIの設計が、
例外投げるようになってたとしたらうっとおしいだろうなあということ
476:デフォルトの名無しさん
07/09/05 20:44:31
parseIntの場合も、本音で言うと多値よりnull返す方が良いと思ってる。ただ、
現状のJavaでは、nullを許容する/しないを型で表現できないという欠点が
あるので、微妙なところではあるけど。
477:デフォルトの名無しさん
07/09/05 20:46:57
はぁ？
478:デフォルトの名無しさん
07/09/05 20:55:41
C#のNullableは安易にstructをサポートしたがために招いた失敗仕様の名残じゃないか
オートボクシングでラッパーオブジェクトと用意に相互変換可能な現状で、んなもん無用の長物
479:デフォルトの名無しさん
07/09/05 21:53:06
使用できる範囲は限定されるが
int parseInt( String numberInString, int defaultValue )があればよかった。
パーズこけたらデフォルト値を返す。
480:デフォルトの名無しさん
07/09/05 21:55:44
そんなに1行で書きたいんですか
481:デフォルトの名無しさん
07/09/05 21:58:55
ラッパークラスに例えばisConvertable(String)みたいなメソッドがないのがねぇ。
2回パースするくらいなら例外でいいっしょｗｗｗｗｗｗって設計思想はちょっと。。。。
482:デフォルトの名無しさん
07/09/05 21:59:23
>>479
ドトネトのTryParseだな。
URLﾘﾝｸ(www.atmarkit.co.jp)
483:デフォルトの名無しさん
07/09/05 22:06:09
>>482
Javaだと参照渡しがないし、標準でmutableなintのラッパークラスも無いから作りにくい。
484:デフォルトの名無しさん
07/09/05 22:08:38
俺はjava.util.prefs.Preferencesのget()を思い出した
485:デフォルトの名無しさん
07/09/05 22:13:18
>>483
プリミティブを参照渡しさせない仕様なんだから
可変にしちゃったらラッパークラスにならないぞ
486:デフォルトの名無しさん
07/09/05 22:18:43
>>483
つ java.util.concurrent.atomic.AtomicInteger
っても、atomicな更新のためのクラスだから
mutableなintのラッパークラスとして使うのはアレな感じもするけど
487:デフォルトの名無しさん
07/09/05 23:17:23
org.omg.CORBA.IntHolder
CORBAのクラスなのがあれだが
488:デフォルトの名無しさん
07/09/05 23:25:19
>>478
C#のNullableは単に値型でnull許容可能にするための代物。
俺が言ってるのは、値型/参照型区別無くある型の変数に
nullを許容する/しないを指定できる代物。しかも、nullableな型は
non-nullableの型にそのまま代入しようとしたらエラーになって
コンパイラによるチェックを強制されるようなの。具体的な言語で言うと、Nice
URLﾘﾝｸ(nice.sourceforge.net)
がそれをサポートしてる。使ってみればわかるけど、この機能はかなり便利。
489:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/09/05 23:39:25
この機能が無いからNullObjectが出来たんだな
491:デフォルトの名無しさん
07/09/05 23:45:26
>>489
それ、何が嬉しいのか分からん。
parseInt だと実行時例外で例外処理を強制できないから、
nullチェック強制できる >>489 の方が良いって話？
492:デフォルトの名無しさん
07/09/05 23:47:05
よく考えてみたらオートボクシングめんどくせえなｗ
これ
493:デフォルトの名無しさん
07/09/05 23:54:52
>>491
パーズ失敗を例外で扱うのに反対で、返り値でパーズ失敗を扱いたいんだけど、
nullでパーズ失敗を表すとしたらNullPointerExceptionの危険性があるし、意図が
あいまいになる危険性もある。で、この機能があればnullを許容するという事を
明示できるし、NullPointerExceptionの危険性も無いから欲しいなあということ。
494:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/09/06 00:03:19
結論はおまえにはjavaは合ってないって事だな。
話聞いてると考え方が短いコードで実現させるタイプの動的言語の発想だ。
496:デフォルトの名無しさん
07/09/06 00:04:38
で、何故parseInt()のパーズ失敗を例外で扱うのに反対かというと、parseInt()は
引数から返り値が一意に定まるので、たとえパーズ失敗でも例外的な状態と
言えないと考えるから。
497:デフォルトの名無しさん
07/09/06 00:06:27
>>495
なんで動的言語が関係してくるの？むしろ静的にチェックできる機能が
欲しいって話をしてるわけで、動的言語とは対極の発想だよ。というか、
短いコードが好ましいってのは動的言語特有の発想でもないでしょ。
498:デフォルトの名無しさん
07/09/06 00:07:59
> メソッド側にアノテーションで実現することになりそうだ。
メソッド側にってのは余計。構成してて放置したままだった。
499:デフォルトの名無しさん
07/09/06 00:15:42
契約的言語。
500:デフォルトの名無しさん
07/09/06 00:21:29
アノテーションひとつで
if (n != null) { /* n アクセス */ } と
if (n == null) { return; } /* n アクセス */
のどちらかを選択（および強制）できるのなら歓迎かな。
@Overrideの親戚みたいなもんだ。
501:デフォルトの名無しさん
07/09/06 00:43:04
例外を「例外的な状態でのみ使うべき」というのは言葉が同じだからもっともらしく
聞こえてしまうだけで、何の助けにもならない方針。
URLﾘﾝｸ(www.boost.org)
URLﾘﾝｸ(boost.cppll.jp)
502:デフォルトの名無しさん
07/09/06 00:48:46
>>500
FindBugsをどうぞ
URLﾘﾝｸ(findbugs.sourceforge.net)
503:デフォルトの名無しさん
07/09/06 01:03:12
>>493,496
単に自分の考えと合わないってだけ？
それって自前のクラスメソッド書いて、そっち使うんじゃダメなんか？
なんつーか、>>448-449 あたりが結論になりそうな話じゃねーかと。
504:デフォルトの名無しさん
07/09/06 01:14:56
>>503
もちろん自前のクラスメソッド書いて使うことになると思うよ。
実際にJavaプログラム書くときの解決策としては。単に言語の
拡張まで含めて許されるならどういう設計にするのが良いかという思考実験。
あと、free論争とは文脈が違うので一緒にされるのはちと心外だな。
どういう方針でライブラリ設計をするかという話は使い勝手に関わって
くる。もちろん、ここで議論しても実際のJava APIの設計が改善されない
という意味では無益なのはそうだけど。
505:デフォルトの名無しさん
07/09/06 01:26:05
>>496
理解できない
すべての失敗する引数はnullが返ることで一意に定まるということ?
例外的な状態かどうかはparseInt単体でなく、呼出し側がどうしたいかでも異なるはずだ
デフォルト値が定まる場合と定まらない場合、とか
んで、とりあえず保守的にパーズ失敗を例外として扱うと言う設計でよいと思う
checkedかどうかは微妙なとこだが
506:デフォルトの名無しさん
07/09/06 01:26:52
単に好き嫌いの問題で、パフォーマンスとか関係ないんでしょ？
free論争と大して変わらんと思うが。
507:デフォルトの名無しさん
07/09/06 01:30:33
>>504
parseInt の使い勝手を改善する事により、Java での開発効率が 10％向上するんだ！
とか考えてるなら 一生懸命考えるのも頷けるんだけど……
ぶっちゃけ瑣末な問題じゃね？
508:デフォルトの名無しさん
07/09/06 01:40:40
例外を握りつぶすユーティリティメソッド作ればOK。
509:デフォルトの名無しさん
07/09/06 02:03:58
>>505
> すべての失敗する引数はnullが返ることで一意に定まるということ?
そういう意図で書いた。正確に言うと、外部の状態に依存せずに
入力*のみ*から返り値が決定される、ということ。その逆の
典型的な例としてはIOExceptionを発生させるような関数や
コンストラクタがある。これらの関数は入力だけでなく外部の
状態によって成功したり失敗したりする。
>>507
parseIntだけの問題として考えればぶっちゃけどうでもいいけど、
一般的な問題としてある関数が失敗を返り値で通知するか
例外で通知するか、というのは瑣末な問題じゃないと思う。
510:デフォルトの名無しさん
07/09/06 09:42:29
ユーティリティメソッド作ればOKってのは、思考停止以外のなにものでもない。
511:デフォルトの名無しさん
07/09/06 09:46:39
parseInt を改変しようとか考えるのは暇人以外のなにものでもない。
512:デフォルトの名無しさん
07/09/06 09:53:09
>>511
そうか？
513:デフォルトの名無しさん
07/09/06 10:14:54
>>511
つきあってた連中も暇人以外のなにものでもない。
514:デフォルトの名無しさん
07/09/06 11:20:14
改変は、ちゃんと考えてbugparadeにあげるなどすれば、なにがしかの影響は与えられる。
ここで改変について語るのも、そういったヤツのインスピレーションになることもあるだろうし、本人が書き込むこともあるだろう。
無駄ではないよ。
515:デフォルトの名無しさん
07/09/06 11:39:06
なにがしかの影響って……
>>509 も parseInt に関してはどうでもいいって言ってるんだが。
そんな瑣末な問題に関わらせる事で
JDK開発者のモチベーションを下げたいって事か？
free論争ってさ、やってる当事者は引っ込みがつかなくなってるだけかと思ってたけど
案外、>>514みたいに「この議論は無駄ではない」とか思ってる人も居るのかも知れないね。
516:デフォルトの名無しさん
07/09/06 11:41:41
parseIntの例外が例に挙がって
- コードを短く書きたい
- 例外で扱う状況とは思えない
という2点の争点があると思う。
さらに後者の視点は、
- 例外を扱うべき状況を設計の美しさから考える
- 例外を扱うべき状況をException処理の重さから考える
という2つの立場がある
俺は、parseIntに例外の記述が出てきてもいいが、重いException処理が
いやだなぁ、という点から、こういうのがあればいいんじゃないかと思う。
定義済Exception/ StaticException / 短距離Exception /LightWeightException ?
今、Exception処理が重いのは、Exceptionオブジェクトの生成にある（スタックトレース生成など）
つまり、生成処理をなくしてやれば大幅にパフォーマンスは改善するはず。
なので思い切って、stackTraceとかが空っぽのExceptionで
すぐ直上のcatch節で捉える決まりで、
さらにThrowの必要があるときは別のExceptionにしなくてはいけないようなもの。
気軽に例外が投げられるようになって、正常系の処理が例外でトリッキーに実装されるように
なっちゃうかもしれないけど、こういうのってどうですかね。
517:デフォルトの名無しさん
07/09/06 11:47:27
>>515
相手にするから調子に乗るんだろ。ほっとけ。
518:デフォルトの名無しさん
07/09/06 12:05:24
>>516
> 重いException処理がいやだなぁ、という点
いやなだけなのか。
これこれこういう使い方をすると、
（パーズ失敗する）parseInt の呼び出しがボトルネックになって困る、
そして、このような使われ方をする事が多いので標準APIを改善して欲しい、
ってんなら議論の余地もあるけど、それって単なる好き嫌いの問題じゃね？
519:デフォルトの名無しさん
07/09/06 12:39:29
>>518
包丁一本で、何でも作るのって大変じゃないかな、って話です。
URLﾘﾝｸ(sourcepost.sytes.net)
のコード書いて、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:デフォルトの名無しさん
07/09/06 12:53:24
>>519
> 数字でないものも大量に含むフィールドがあれば
普通はフォーマットエラー吐いて終わりでしょ。
521:デフォルトの名無しさん
07/09/06 13:10:14
〃〃∩ _, ,_
⊂⌒（ `Д´） ＜ ヤダヤダ！ parseInt が例外使っちゃヤダ！
｀ヽ_つ ⊂ノ
ジタバタ
〃∩
⊂⌒( _, ,_） ＜ ぶっちゃけどうでもいいけど、やっぱりヤダヤダ……
｀ヽ_つ ⊂ノ
ﾋｯｸ...ﾋｯｸ...
⊂⌒( _, ,_）
｀ヽ_つ ⊂ノ zzz…
522:デフォルトの名無しさん
07/09/06 13:56:24
delphiのStrToIntDefみたいに、数値にできないときのデフォルト値が指定できればかなりいい
523:デフォルトの名無しさん
07/09/06 14:17:51
>>520
何で？全部読んで例外をチェックしないと駄目かもしれないですよ。
いや、というか例外を使うなとかいう話ではなく、
パフォーマンスを気にして例外を使うべき場面を回避しようとするのは
本末転倒だから、例外を使わなきゃ駄目なときパフォーマンスが
落ちなければそういう誤解、というか誤用がなくなるんじゃないかと。
524:デフォルトの名無しさん
07/09/06 14:45:35
>>523
「かもしれない」って……
要するに、今現在（パーズ失敗する）parseInt の呼び出しが
ボトルネックになって困ってるわけじゃないんでしょ。
単なる好き嫌いの問題にしか見えないが。
それに、誤用とか誤解とか言われても……
>>509の理論が いつでもどこでも通用する例外のガイドラインとはとても思えないし、
使い勝手、堅牢性、パフォーマンス、好き嫌いとか色々な要素が絡んでくるから
いつでもどこでも誰にでも通用する例外のガイドラインを作るのは難しいだろうし。
525:デフォルトの名無しさん
07/09/06 14:47:32
ということは例外はこれまでどおりフィーリングとわずかなドキュメントで判断していくしかないのかね
526:デフォルトの名無しさん
07/09/06 15:21:46
>>524
>>523 ≠>>509です。
parseIntはあくまで例です。
確かにちょっと誤解されそうなレスでした・・・
誤用というのは、Exceptionを使うまいとして
ごちゃごちゃとしたコードになってしまうような状況を指してます。
具体的にカチッとした基準に基づいた「ごちゃごちゃ」ではありませんが。
私は、parseIntに関わらず、Exception処理が軽くなればいいな、という話をしているつもりでした。
527:デフォルトの名無しさん
07/09/06 15:36:41
>>526
parseInt で例外生成コストが下がると嬉しいか？
それに、parseInt で Exceptionを使うまいとして
ごちゃごちゃとしたコードになるって、どんな状況？
あと、俺は Exception処理が軽くなれば良いって要望に対する返答が
「例外的な状況以外で例外使うな」って話なんだと理解してるんだが。
例外って濫用すれば goto より悲惨なスパゲッティコード書けるしね。
528:デフォルトの名無しさん
07/09/06 17:31:04
パースの失敗は十分、例外的状況に値すると思うが・・・。
例外処理の乱用がスパゲッティーコード招いてるんじゃなくてそういうコード書いてる自分がスパゲッティー作ってるんだと思う。
アプリケーションかミドルウェア側の設計でどうにかなると思うんだが？
529:デフォルトの名無しさん
07/09/06 17:37:48
>>527
InterruptExceptionって例外的だと思う？
スレッドのキャンセルを実装しようと思ったら普通に出るけど
530:デフォルトの名無しさん
07/09/06 18:49:35
>>528
設計っつーか、実装で吸収できるでしょ。
531:デフォルトの名無しさん
07/09/06 20:19:45
便利なら便利なほうがいい。
532:デフォルトの名無しさん
07/09/06 20:24:49
何を便利と感じるかは人によって違う、と。
かと言ってなんでも標準APIに入れたら標準APIメンテする人間の負担が増えて
バグが増えたり放置されたりといった悪影響も考えられる、と。
533:デフォルトの名無しさん
07/09/06 20:47:42
NICEのnullableってのは興味深いネタだったけど、
それと一緒に語られたparseIntの仕様には何の興味も湧かなかった。
つーことで、イディオム補完型（保証型）のアノテーションの充実を期待したい。
534:デフォルトの名無しさん
07/09/07 07:32:33
>>445
終了前のfreeは害っていうのがいるだろ。
535:デフォルトの名無しさん
07/09/07 07:55:31
そんなものは無い
536:デフォルトの名無しさん
07/09/07 22:37:51
URLﾘﾝｸ(blogs.wankuma.com)
537:デフォルトの名無しさん
07/09/07 22:39:06
URLﾘﾝｸ(blogs.wankuma.com)
538:デフォルトの名無しさん
07/09/08 00:14:55
parseIntで100近くもダベれるお前らに脱帽
539:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/09/08 01:03:04
>>539
例外を使ってるバージョンが100倍近く遅いんだが、それは
有意な差じゃないの？
541:デフォルトの名無しさん
07/09/08 01:05:19
あ、もちろん実際にparseIntが使われる局面で1000000万回も
呼ばれることは無いだろうから、そういう意味では例外を使っても
いいんだろうけど、有意な差が無いってのは変でないの？ってこと
542:デフォルトの名無しさん
07/09/08 01:05:27
>>539
ネタにマジレス。
まず 数値チェックに parseInt 使って
> クリティカルで速度が要求される場面
が具体的にどういう場面なのかってのを特定するのが先決。
それをしないで「どういう処理が望ましいか」を考えても時間の無駄。
543:デフォルトの名無しさん
07/09/08 01:07:45
間違った。1000000万回 -> 1000万回
544:デフォルトの名無しさん
07/09/08 01:12:44
>>538
まだまだ続くよ
545:デフォルトの名無しさん
07/09/08 01:59:22
巫女巫女ナース巫女巫女ナース♪
546:デフォルトの名無しさん
07/09/08 02:32:19
｢まだまだ いくよぉ～｣だな
547:デフォルトの名無しさん
07/09/08 03:09:27
もうちょっとだけ続くのじゃ
548:デフォルトの名無しさん
07/09/08 07:03:01
つうか、例外は制御構造の要だろ
URLﾘﾝｸ(d.hatena.ne.jp)
549:デフォルトの名無しさん
07/09/08 08:05:55
多値にしてもnullableにしても、
失敗をnullで表すのはちょっと古いんじゃないかな。
多値なら失敗(false)したら(undef, false)とundefみたいな値を返す方がいいと思う。
550:デフォルトの名無しさん
07/09/08 10:19:24
>>544,547
続けるなよ……
551:519
07/09/08 14:09:14
>>536
ちょっと待て、ほとんど俺が書いたコードじゃねえかそれ。
ちなみに、おれじゃねえぞ。そのblog
552:デフォルトの名無しさん
07/09/08 14:18:22
>>549
undefがnullとどう違うのかわからん
553:デフォルトの名無しさん
07/09/08 15:06:37
>>552
お前はそもそもnullは何をモデル化したと考えてるんだ？
554:かつのり
07/09/08 16:03:23
本人降臨っす。
>>519
実験用にパクらせていただきましたｗ
ちなみにStringUtils.isNumeric()は微妙ですね。
Integer.parseIntの高速版とするなら、
Integerとしての要件を満たさなければいけません。
正規表現のパターンを予めキャッシュしておいて、
そのパターンでマッチングするのが一番早いのかな。
555:デフォルトの名無しさん
07/09/08 16:29:24
NumberUtils#isNumberもあるけどlong型とかでも判定しちゃうな
556:519
07/09/08 17:34:45
>>554
ああ、バッチでファイル読む時は俺もそうしてるなぁ
どうせ桁数制限とか入る事が多いし
557:デフォルトの名無しさん
07/09/08 17:52:06
Patternのcompileってホントにコンパイルしてるの？
558:デフォルトの名無しさん
07/09/08 18:01:25
>>557
コンパイルの意味を、パースして実行用データ作っとくって意味なら、コンパイルしてるんじゃねぇの？
559:デフォルトの名無しさん
07/09/08 18:21:18
たしかに最適化オプション付きであるとはいってないからね。
Strategyパターンとか駆使してガチガチに最適化されたPatternを返して欲しいとこだ。
560:デフォルトの名無しさん
07/09/08 19:03:46
Javaの正規表現はDFAでしょ？確か。
DFAはバックトラックしなくていいから、
最適化は高速化ではなく使用メモリのレベル。
遷移テーブルとかその辺。
下手な自前のマッチングコードを書くより早いよ。正規表現は。
561:デフォルトの名無しさん
07/09/08 19:55:04
>>560
Javaの正規表現はNFA。実装読んでみるべし。
最近の言語に組み込みの正規表現ライブラリの多くはNFA(または
その変種)を採用してる。理由はNFAじゃないと扱いづらい機能
(後方参照など)があるため。
562:デフォルトの名無しさん
07/09/08 19:56:36
ちなみに各言語における正規表現ライブラリの実装がどのように
なっているかの概要を知りたい場合は、詳説正規表現がオススメ
563:デフォルトの名無しさん
07/09/08 22:35:20
>561
そか。情報サンクスコ
564:デフォルトの名無しさん
07/09/09 19:28:16
DFAじゃあ不便すぎる。
565:デフォルトの名無しさん
07/09/09 21:49:32
DFAはNFAから変換できるけど、NFAにしておく意義としては、
NFAのまま何かの機能を追加するってこと？
バックトラックする際に後方参照も同時にサポートするためなのか。
566:デフォルトの名無しさん
07/09/09 22:28:17
>>560
> 下手な自前のマッチングコードを書くより早いよ。正規表現は。
んなわけねーだろ。正規表現遅すぎだ。計測してねーだろ。
ただ、Web アプリとかでせいぜい項目が数百程度の
入力チェックや変換程度なら速度差は計測不能。
567:デフォルトの名無しさん
07/09/09 22:41:57
>>566
単純な文字パターンの検証なら正規表現の方が遅いだろうけど、
ごく一般的な業務システムプログラマが、
自前で複雑な検証コードを書くよりは速い。
きちんとロジックを書ける人なら速いんだけど。
568:デフォルトの名無しさん
07/09/09 23:18:56
文脈的に parseInt でパーズ成功/失敗を予め判定するためのコードでしょ。
>>554が言うように Intergerとしての要件を満たす、
文字列が数字で構成されてるかだけじゃなくて最大値や最小値チェックもするなら
正規表現つかうより自前でやった方が早く書けるんじゃねーの？
569:デフォルトの名無しさん
07/09/09 23:23:20
最大値や最小値をチェックする時点で、成功/失敗を予め判定するどころか、すでに値が求まってる気がする
570:デフォルトの名無しさん
07/09/09 23:56:08
>>566>>567>>568
>>560は正規表現エンジンがDFAで実装されてる場合の
話をしてると思うよ。その場合なら、下手に自前の
コード書くより早いというのは間違いでもなんでもないよ
571:デフォルトの名無しさん
07/09/10 00:01:33
> ちなみにStringUtils.isNumeric()は微妙ですね。
> Integer.parseIntの高速版とするなら、
> Integerとしての要件を満たさなければいけません。
だからなぁ…… 最大値/最小値チェックしないなら
ほとんどStringUtils.isNumeric()で用足りるんじゃね？
572:デフォルトの名無しさん
07/09/10 00:01:37
>>565
そういうこと。NFAのままにしておけば、「非正規な」機能である後方参照
やその他もろもろ、比較的容易に追加できる
573:デフォルトの名無しさん
07/09/10 00:13:43
>>569
例外使わないだけで 100倍程速くなるそうだから、
変換処理が 2回やる事によって 2倍の時間かかっても大した問題じゃないんじゃね？
まぁ、場合によっては大した問題になるかもしれんが。
そんなん問題になってから考えりゃいいっしょ。
574:デフォルトの名無しさん
07/09/10 01:42:54
正規表現使うほうが１００倍速いよ。実装が。
575:デフォルトの名無しさん
07/09/10 20:17:24
C#の正規表現はグループに名前を付けられるみたいだね
576:デフォルトの名無しさん
07/09/10 21:14:45
>>574
StringUtils.isNumeric()では足りない部分までIntegerの要件を満たすかチェックするんだったら
正規表現でやるのは面倒くさそうだが。
577:デフォルトの名無しさん
07/09/10 22:50:21
正規表現のスレでやれよ。ここには関係ないから。
578:デフォルトの名無しさん
07/09/10 23:04:10
>>576
桁数制限してIntegerの半分以上の範囲捨てるなら簡単だけどな
579:デフォルトの名無しさん
07/09/12 00:32:10
>>575
正規表現のマッチング処理高速化のためにコンパイルすると、
メモリリークするとかＭＳＤＮのドキュメントに書いてあるけどな。
580:デフォルトの名無しさん
07/09/12 00:53:38
>>579
それドトネト1.1のころの制限じゃない？
581:デフォルトの名無しさん
07/09/15 10:08:16
なんと言う次世代
582:デフォルトの名無しさん
07/09/15 10:59:42
次世代試作機・・・。
583:デフォルトの名無しさん
07/09/15 13:48:51
Javaを拡張するのではなく、OSを拡張するというのはJSRにならんのかね？
例えばjinputをJava標準にするための下地にするためにとか。
584:デフォルトの名無しさん
07/09/15 14:16:31
JDK7 build20
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
585:デフォルトの名無しさん
07/09/15 19:49:01
そういやjdk7が出来たらOpenJDK6をOpenJDK7ベースで再構築してOpenJDK6をGPL2で配布するらしいな。
将来的には公式バイナリも完全にOpenJDKからビルドするらしい。
586:デフォルトの名無しさん
07/09/16 12:58:01
７は変な機能増えすぎ
もっとシンプルに保てよ
587:デフォルトの名無しさん
07/09/16 13:16:10
クロージャというか関数導入するならperl見たいな複数戻り値の関数もできるようにしてくれ
588:デフォルトの名無しさん
07/09/16 14:09:47
多値返せたらいいのにと思うことはよくある
589:デフォルトの名無しさん
07/09/16 15:38:35
時々、妙に多値希望の人っているよね
そういう人はロートルだと思っておｋ？
590:デフォルトの名無しさん
07/09/16 15:39:53
多値が返せる言語ってあるの？
591:デフォルトの名無しさん
07/09/16 15:44:03
Perlしかしらない。
ただstateとvalueみたいな多値が欲しいがために
ReultFooみたいなクラスを書くのはなんだかなぁと思うときは多い。
592:デフォルトの名無しさん
07/09/16 16:23:13
lispまでいくと多値というよりリストか
Object[]のシンタックスシュガーで十分なんだけどな
C#のstructなんかよりずっと有用
593:デフォルトの名無しさん
07/09/16 17:16:56
pythonのtupleみたいなの。
まあ、Object[]でもいいけど。
>>591みたいな
型に名前つけるのが面倒なんだよ。
594:デフォルトの名無しさん
07/09/16 19:17:12
Pair<A, B> みたいなクラスを作って使いまわすとか
595:デフォルトの名無しさん
07/09/16 19:48:49
最近は多値返せる言語増えたよ。
javaだとどうせバイトコードレベルでは配列になるんだろうね。
596:デフォルトの名無しさん
07/09/16 20:16:58
public const<String, Boolean> getResult() {
return const { "おｋｗｗｗｗ", true };
}
こんな感じで死にキーワードを流用できないものか
597:デフォルトの名無しさん
07/09/16 20:20:27
>>596
それだったら Pair<A, B> で良いじゃん。
598:デフォルトの名無しさん
07/09/16 20:26:16
普通のGenericsは可変長じゃねー
599:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/09/16 20:49:41
こらこら。Javaにrefやoutはないでしょ。
尤もCommonsLangあたりにはあっていいクラスだとは思うけど
601:デフォルトの名無しさん
07/09/16 20:52:29
ref や out って、どこの話だ？
602:デフォルトの名無しさん
07/09/16 20:52:37
多値よりも Ref<T> のほうがまだ使い勝手が良さそうな気がする。
603:デフォルトの名無しさん
07/09/16 20:53:37
ああ、ファクトリメソッドか、俺の勘違い。
>>601 C#
604:デフォルトの名無しさん
07/09/16 20:55:55
>>603
いや、レス番の話。
このスレのどこで ref や out の話が出てんのか、と。
605:デフォルトの名無しさん
07/09/16 20:57:38
俺が>>601をクラス定義と勘違いしただけだって。
606:デフォルトの名無しさん
07/09/16 20:59:21
あ、>>599ね。あかん、おねむの時間っぽい。
607:デフォルトの名無しさん
07/09/16 21:03:13
>>599 にも ref や out があるようには見えんが……
608:デフォルトの名無しさん
07/09/16 21:04:09
どう勘違いしたのかくらい考えろ馬鹿ちん
609:デフォルトの名無しさん
07/09/16 21:07:16
なんだ、勘違いか。なら考えても無駄だな。
610:デフォルトの名無しさん
07/09/16 21:09:24
遅かれ速かれ多値はサポートしてくれるものと思いたい。
611:デフォルトの名無しさん
07/09/16 21:10:54
JVM系LLで多値サポートしてたら、そっち使えって話になるんじゃね？
612:デフォルトの名無しさん
07/09/16 21:15:23
var rand = new Random();
int n = rand.nextInt();
みたいな書き方も需要あるから、多値もJSRには上がるとは思う。
613:デフォルトの名無しさん
07/09/16 21:17:32
URLﾘﾝｸ(bugs.sun.com)
will not be fixed になってる。
614:デフォルトの名無しさん
07/09/16 21:23:36
>>612
どうだろね？
型推論ですら、変数宣言時の型指定を省くのは Java 的じゃないってんで
G<T> g = new G();
みたいに、初期化子の方のパラメタ型指定を省けるようにしようって
論調の方が強いみたいだけど。今までの
G<T> g = factoryOfG();
みたいな型推論とも一貫性あるってのが良いらしい
615:デフォルトの名無しさん
07/09/16 21:28:40
G<T> g = new(); みたいなのもどっかで見たな。
616:デフォルトの名無しさん
07/09/16 21:31:31
極力interfaceで受け取れいうてる今までとの親和性の問題もあるし、
今後の拡張はローカルキーワードで行きたいって思惑もあるから
早い段階でサポートするならそっちかもな
>>615
みたけど流石にそれはないｗ
617:デフォルトの名無しさん
07/09/16 21:42:13
varの方はGraphicsEnvironment.getLocalGraphicsEnvironment()とか長すぎるから何とか汁って考えもあったはず
618:デフォルトの名無しさん
07/09/16 21:47:32
>>617
つ static import
619:デフォルトの名無しさん
07/09/16 21:49:48
staticじゃなきゃ役にたたねーけどね
620:デフォルトの名無しさん
07/09/16 21:52:21
メソッド名が長いのはメソッド名のalias導入とかせんと解決せんのでは？
621:デフォルトの名無しさん
07/09/16 21:54:22
関係ないけど、メソッド名ってたしか長さ制限あったよね
622:デフォルトの名無しさん
07/09/16 22:00:53
static importはユーティリティメソッドに
沢山依存してる状態じゃないと返って面倒なだけ
623:デフォルトの名無しさん
07/09/16 22:05:31
名前空間が汚れる。
624:デフォルトの名無しさん
07/09/16 22:06:13
まあ、結局のところD言語はvarで解決としたみたいだからJavaもそうなるよ。
プロパティ問題も馬鹿なことやらないで、素直にC#風にしたしね。
625:デフォルトの名無しさん
07/09/16 22:26:52
> プロパティ問題も馬鹿なことやらないで、素直にC#風にした
ソースは？
626:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/09/17 00:01:39
>スタックフレームの返値を格納するスロットが一つ増えるだけだから、
それやると VM の変更が必要にならんか？
> tupleやlistやarrayを箱にする方法より性能がいい。
その辺の性能あげるためにエスケープ解析とか頑張ってるんじゃね？
628:デフォルトの名無しさん
07/09/17 00:02:35
>>627
VMの変更っつーか、VM仕様の変更じゃね？
629:デフォルトの名無しさん
07/09/17 00:07:16
>>625
URLﾘﾝｸ(docs.google.com)
これの事じゃね？
でも、これbeansのプロパティと互換性ないし、
フィールドとプロパティの名前がかぶった場合どうなるかって部分も甘いような。
630:デフォルトの名無しさん
07/09/17 12:14:51
多値はいつか実現して欲しいね。
引数は0個以上なのに、結果は0か1に制限されているのは不便。
>>589
他の言語で使うと癖になるから、粘着的なw要望が続くんだと思う。
631:デフォルトの名無しさん
07/09/17 12:20:52
>>630
なんつーか、Perlとかで初めてsplitの結果を複数の変数に
まとめて入れる表現見たとき便利だと思ったわけで、
こういうのって、返値は配列として扱ってるじゃない。
配列の返値を、各変数に代入するシンタックス糖分があればいいんじゃないかな？
632:デフォルトの名無しさん
07/09/17 13:34:05
> スタックフレームの返値を格納するスロットが一つ増えるだけ
> 配列の返値を、各変数に代入するシンタックス糖分があればいい
この二つって全然別の要求なわけで……
633:デフォルトの名無しさん
07/09/17 13:35:18
>>630
粘着的な要望する奴は口だけ動かして手を動かさんからなぁ……
634:デフォルトの名無しさん
07/09/17 14:09:07
>>632
多値って一口に言っても、考えてる事が微妙に違うからなぁ……
635:デフォルトの名無しさん
07/09/17 14:49:27
とりあえず配列でやっておけばいいんじゃないの？
636:デフォルトの名無しさん
07/09/17 14:52:17
>>635
Object[]を使えばいいじゃんって意味？その場合、複数種類の型を内包する配列を扱うことになるから、
言語的なサポートが欲しいって言ってるんじゃない？
637:デフォルトの名無しさん
07/09/17 14:53:20
>>633
このスレに要望出しても意味ねえんだけどな
638:デフォルトの名無しさん
07/09/17 14:54:47
型の問題があるなら、引数のほうに値をうけとる配列として渡すとかね。
639:デフォルトの名無しさん
07/09/17 14:58:05
>>637
要望だした時点で気持ちよくなってんじゃないかと。
要望を実現する事よりも、気持ちいい事の方が重要なんじゃね？
640:デフォルトの名無しさん
07/09/17 15:48:10
ゆとりのやつって、直接的な効果がなければ意味ねぇとかよく言うよね。
間接的な効果を想像できないんだよね。
641:デフォルトの名無しさん
07/09/17 15:53:01
あるあるｗ
ちょっとたとえを出して、それを否定できただけで、全てを否定ｗ
642:デフォルトの名無しさん
07/09/17 15:53:48
間接的な効果に期待（するだけ）しかできないんだったら
> 要望を実現する事よりも、気持ちいい事の方が重要なんじゃね？
って評価は正しいような。
643:デフォルトの名無しさん
07/09/17 17:26:43
はいはい、ここは次世代Javaのスレですよっと
JSR-310 に generics版なるものが出来ていた。
URLﾘﾝｸ(jsr-310.dev.java.net)
URLﾘﾝｸ(jsr-310.dev.java.net)
> 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:デフォルトの名無しさん
07/09/17 20:18:05
URLﾘﾝｸ(blogs.wankuma.com)
645:デフォルトの名無しさん
07/09/18 08:41:40
generics版は、入力めんどすぎだな
646:デフォルトの名無しさん
07/09/18 16:45:33
ドキュメント簡潔で理解しやすいしこっちのほうが好きなのは俺だけか
それはそうと９月の第三月曜日とか毎月第五土曜日（と、第五土曜日が存在するかチェックする方法）とか
どうやって入力するんだろう？ この程度のことがいちいち煩雑なのは嫌なんだけど。
曜日指定できそうなCalenderDayのDayOfWeekは引数がなぜかint型だし。
曜日関係はまだまだこれからなのかね？
647:デフォルトの名無しさん
07/09/18 20:37:07
あれだ。
カレンダー用のXPathみたいなの作って
W3C標準にすればいいんじゃね？
648:デフォルトの名無しさん
07/09/18 21:04:02
CQL
CalendarQueryLanguage
ばばーん >>647 がただ今鋭意作成中です
649:デフォルトの名無しさん
07/09/18 23:12:45
>>647
Structured Calendar And Time Markup Language
略してSCATML。それのAPIがSCATMLAPI。
650:デフォルトの名無しさん
07/09/18 23:19:52
31日や2月29日みたいなTimeFieldやTimeViewって
カレンダーが背後にあるクラスに受け入れられるまで、意味のあるカレンダーデータかどうかわかんないわけだよな。
ついでにPeriodを加算するみたいな日付計算もできない。
それなら『カレンダーが背後にあるクラス』をインターフェース化しておいたほうがいいんじゃないかと思ったり。
最初はCalendricalがそうかと思ったんだけどなんか違うっぽいな。
651:デフォルトの名無しさん
07/09/18 23:54:39
やっぱCalendricalか。何故かTimeViewやTimeFieldに継承されているけどこれは何かの間違いだな。
weekOfMonthが作れるようになったりTimeField同士を結合してTimeViewを作ったりできねえかな。
そしたら今年の９月の第３月曜日とかでも楽に指定できるのに。難しいのかこれは。
652:デフォルトの名無しさん
07/09/19 00:00:02
TimeAmountで期間データの変換が相互に可能になってるっぽいが
Second～DayはともかくDay～Foreverのデータはカレンダーないと変換できないような。
いちいちUnsupportedOperationException投げるつもりかいな
653:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/09/19 02:54:46
>javax.time.Moments.*
パッケージ名だけ見たらとてつもなく抽象的すぎて何に使って良いかわかりづらいな。
655:デフォルトの名無しさん
07/09/19 03:17:56
TimeUtilsとかの方がいいよな。常識的に考えて。
そのうち変わると思うが
656:デフォルトの名無しさん
07/09/19 11:16:37
>>654
time.Momentsってそんなにわかりにくいかな？
657:デフォルトの名無しさん
07/09/19 13:15:14
個人的にクラス名変えるならこんな感じ
時刻系
TimeView＞TimeExpression：時刻表現
Calendrical＞ScaledTime：カレンダー評価済み時刻表現
TimeField＞TimeField：即値時刻表現
期間系
Period＞Period：期間
TimeAmount＞PeriodField：即値期間
単位系
TimePart＞Unit：単位
その他
Moments＞TimeUtils：ユーティリティクラス
うーん、イマイチ。
658:デフォルトの名無しさん
07/09/19 16:48:46
クラス名・変数名に迷ったら書き込むスレ。Part10
ｽﾚﾘﾝｸ(tech板)
ここにお願いしてみては
659:デフォルトの名無しさん
07/09/19 18:46:41
>>656
今のクラス名だと高精度の時間取得APIとも取れるし、時系列系APIのフレームワークとも取れる。
名前から想像できる用途が曖昧で冗長といった印象。
名前からすると一見汎用性がありそうだけど、
けど中身はカレンダーAPIの上位API程度の印象も受ける。
そのため、今のカレンダーAPIとの関係も分かりづらい。
そうなると移行や使い分けが難しいかと。
要するに何のために作ったのか分からん、と・・・。
660:デフォルトの名無しさん
07/09/19 19:01:06
どう見ても完全に置き換えるものとして使うようにできてるだろ。
互換性を意識しないといけない場合以外は全部移行していいようにするんじゃないのか？
まだOverViewには入ってないがフォーマッティングやパーシング用のクラスも作るらしいし。
661:デフォルトの名無しさん
07/09/19 19:22:46
java.util.concurrent.TimeUnit も忘れないであげて
662:デフォルトの名無しさん
07/09/21 13:05:43
JSR 277とJSR 291は議論が熱いね。
URLﾘﾝｸ(www.infoq.com)
663:デフォルトの名無しさん
07/09/22 10:54:13
OSGi関係は熱そうだね。
関わってるところ多いし、影響が大きそう
664:デフォルトの名無しさん
07/09/24 18:48:55
JDK7、機能はすごい魅力的なんだが、リリースが一年以上先か・・・。
堅実なのはいいことだけど、もうちょっと早くならんかなあ。
665:デフォルトの名無しさん
07/09/25 01:28:48
目玉機能とされてるJSR-277もまだだし
Closureに至ってはJSRすらないしなぁ。
これでリリースまでに全部つっこんできたら十分早いと思うが。
666:デフォルトの名無しさん
07/09/27 22:46:13
業界的にはまだバージョン4が多数だから早い感じもする。
667:デフォルトの名無しさん
07/09/28 00:51:19
テンプレート(1.5)、クロージャ(1.7)とくれば、最後に来るのは…マクロ！(1.9予定)
すべての言語は最後はlispの一部を再実装する事になるのかと思うと、複雑な気分だな。
668:デフォルトの名無しさん
07/09/28 01:00:50
バージョン4なんかない。
669:デフォルトの名無しさん
07/09/28 02:22:08
>>668
R4のことだろ？
670:デフォルトの名無しさん
07/09/28 04:08:52
RhinoR4？ライセンスが・・・ｗ
671:デフォルトの名無しさん
07/09/28 10:11:40
最後はevalだな。
672:デフォルトの名無しさん
07/09/28 11:10:22
OSGiじゃないのか？
673:デフォルトの名無しさん
07/09/28 14:32:28
JDK7 build21
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
だって。
ようやくコンパネの縦長が直った。
674:デフォルトの名無しさん
07/10/09 15:06:09
OSGiかなにかのプラグイン機構がJava SEに入るまでまだ一年位あるので、
Javaのスクリプトで代わりをできないかと思ったんですが、
次を読むと普通にできそうですね。
（つまりJavaプログラム実行中に動的に実行コードを入れ替えたい。）
JavaからRubyスクリプトを実行する
URLﾘﾝｸ(codezine.jp)
個人的にプラグイン機構の重要度がかなり下がりました。
675:デフォルトの名無しさん
07/10/09 15:14:59
普通にクラスローダを使えばいいだけじゃないの？
676:デフォルトの名無しさん
07/10/09 15:26:11
クラスローダは難しい・・・
昔OSGiを使ってたときですらクラスローダで苦労した。
確か、setContextClassLoader辺りとか頻発した。
（OSSのライブラリでこれが設定できないので、プラグインから使うために
ソースを書き換える必要が発生したこともあった。）
記憶が薄れてるけどOSGiが無いとさらに倍以上苦労する感じだったと思う。
677:デフォルトの名無しさん
07/10/10 02:31:03
URLClassLoaderで簡単にJARファイルからクラスを読み込めるから、
プログラム実行中に動的に実行コードを入れ替えるのは簡単だと思うけどな。
678:デフォルトの名無しさん
07/10/10 08:53:59
>>674
Rubyてw
Javascript使えよ。最初からSEに入ってんだから。
679:674
07/10/10 13:46:54
助言？ありがとうございます。
>>677
setContextClassLoaderは、Jar内のファイルを読むために
基盤とプラグインのJarのClassLoaderを切り替える
のに使ってたんだったと思いますが、
URLClassLoaderを使うと簡単にできそうな気がします。
>>678
JRubyは速いと言う記事が目に入ったので
条件反射で調べてみたのですが、
JavaScriptでいいですね。Rubyは殆ど知らないし。
680:674
07/10/10 13:49:23
ちなみにやりたい事は、
UMLのステートチャート図で状態遷移を定義しXMLを生成する
（このエディタは自作する）
実行時はXMLに従って、各状態と遷移時の処理を行う。
基本的に、ステートパターンで実現する。
こんな感じの多目的に使えるフレームワーク作り。
と言う感じで、DIコンテナで普通にできそうですね…。
それが一番早いなｗ
681:デフォルトの名無しさん
07/10/10 16:20:30
>>677
具体的にどういうコードになるの？
クラスローダーは複雑で言ってる事が見えてこない…
682:デフォルトの名無しさん
07/10/10 16:44:08
>> 681
丁度いいページがあったので勝手にリンクさせてもらいます。
URLﾘﾝｸ(homepage3.nifty.com)
683:デフォルトの名無しさん
07/10/11 03:45:19
JRubyは本家と比べて早いって意味だ。
まあ、宗教は自由だぜ！
684:デフォルトの名無しさん
07/10/11 09:54:50
>>682おお、そういうことか！
685:デフォルトの名無しさん
07/10/13 23:07:55
そろそろクロージャの仕様決まった？情報まだぁ
686:デフォルトの名無しさん
07/10/13 23:23:22
URLﾘﾝｸ(www.javac.info)
URLﾘﾝｸ(www.javac.info)
URLﾘﾝｸ(www.javac.info)
あたりは動いてないね。JCPのJSRのリストにも登録されてないみたいだし。
他の場所では動いてるのかも知らんけど
687:デフォルトの名無しさん
07/10/13 23:49:45
ああ、いろいろプロポーズはあるみたいだけどそれが採用されそう。
688:デフォルトの名無しさん
07/10/14 01:16:57
簡単に読み書きできることが重視されるJavaでは導入が難しいのかも。
クロージャに結びつけた変数に対して破壊的操作を行うプログラムを書いちゃうと、
非常に理解が難しいプログラムになる。と某所で言われていた。
689:デフォルトの名無しさん
07/10/14 01:28:27
staticメソッドとクロージャを組み合わせて制御文みたいなのを作れるのは面白いと思ったけど
フォールスルーしないswitch文みたいなのは無理かね
690:デフォルトの名無しさん
07/10/14 02:13:48
クロージャ、クロージャ言うけどクロージャ導入しても元々クロージャに書き換えるようなメソッドなら
コンパイル時にインライン化されてるだろうから人がクロージャ書く意味ってあるか？
JavaScriptも使うからクロージャは大好きだが・・・。
691:デフォルトの名無しさん
07/10/14 02:20:41
うん、無理っぽいな。できたとしてもがcaseに指定された値が定数かどうかを判別するすべがないから意味ないし
String line;
while ((line = br.readLine()) != null)
みたいなループをfor eachLine(String line : br)みたいには直せそうだ。あんまりいい例じゃないが
>>690
コストが低いからクロージャを使うわけじゃないだろ
692:デフォルトの名無しさん
07/10/14 03:35:29
いいかげんプリプロセッサとはいわんからせめて#ifdefを導入しろよ
693:デフォルトの名無しさん
07/10/14 03:46:15
＞＞６９０
わかりやすいから使うんじゃないのか？
いい加減いちいち無名クラスを宣言するのめんどうになってきたよ。
694:デフォルトの名無しさん
07/10/14 04:47:24
もう関数型のパラダイム全部入れちゃえばいいじゃんｗ
695:デフォルトの名無しさん
07/10/14 05:53:53
どうせこうなるんなら最初からいれちゃえばよかったのに
696:デフォルトの名無しさん
07/10/14 13:56:40
クロージャが、多重継承のようにうまく使えば有用だが弊害もある機能だったらどうするんだ？
Javaはハッカー向け言語ではなく一般向け言語なんだし、彼らが誤用しにくい機能であるか検証しなければならない。
697:デフォルトの名無しさん
07/10/14 14:24:52
どのように有用？
別に一般向けでないが？
自分で使いこなせればよいだけだし？
おまえ、キモイ顔しているんだろうな。
698:デフォルトの名無しさん
07/10/14 14:27:52
>>692
既にあるにはあるだろう。
699:デフォルトの名無しさん
07/10/14 14:50:31
根本的には関数型言語のパラダイムを中途半端に取り入れるのが不味いんだろうな。
だれか、両方を統合するようなアイデアを発明してくれればいいんだが。
700:デフォルトの名無しさん
07/10/14 15:46:57
ところで、>>696は一体全体何を主張したかったのだろうか…謎は深まるばかりだ…
701:デフォルトの名無しさん
07/10/14 16:55:18
>>699
命令型と関数型で、破壊的代入の在る/無しという根本的な前提が異なっているからなぁ。
この大きく異なる前提を乗り越えて上手く使える機構が欲しいね。
702:デフォルトの名無しさん
07/10/14 17:07:59
不変なオブジェクトを渡すか防衛的コピーして渡すか変更不可能なビューを渡すかすればいい話なんじゃないのか
Immutableオブジェクトを作るときと同じじゃん
703:デフォルトの名無しさん
07/10/14 17:09:24
その違いがなくなると、命令型と関数型の垣根がなくなってしまうし、いくら欲しくても乗り越える事はできなだろう。
704:デフォルトの名無しさん
07/10/14 18:53:24
>>688
int な変数を final int[] みたいに似非参照化して
内部クラスや匿名クラスで使えば結局同じ事になるけど、
記述が容易になると初心者が躓く可能性が高いとかそーゆー話？
URLﾘﾝｸ(docs.google.com)
CICE とかの public int みたいな構文糖の方が良いって話か？
705:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/10/14 19:27:18
そんなに難しく考えなくともecma-262とかScalaがあるじゃないか。
両立は可能だ。
707:デフォルトの名無しさん
07/10/14 19:48:05
>>705
return method.invoke( obj, args );じゃなくて
return method.invoke( t, args );だわ
そういやobjはプロキシインスタンスだった
708:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/10/14 19:53:00
>>708
CICEとBGGAごっちゃになってねーか？
710:デフォルトの名無しさん
07/10/14 20:54:04
>array.each{int item => total += item;}
こういう文は見慣れない奴はインデントに困るだろうな。
array.each{ int item =>
total += item;
}
711:デフォルトの名無しさん
07/10/14 21:15:14
array.each(
{int item => total += item;}
);
こういうインデントは？
712:デフォルトの名無しさん
07/10/14 21:35:40
>>711みたいに>>710のインデントを知らん奴がいるから混乱するんだ。
713:デフォルトの名無しさん
07/10/14 21:50:42
>>712
インデントにうるさいおまえと一緒だと疲れる
714:デフォルトの名無しさん
07/10/14 22:33:45
インデントにうるさい言語があったよな。おまえはそれを使ってればいい
715:デフォルトの名無しさん
07/10/14 22:53:03
ぱいそん
716:デフォルトの名無しさん
07/10/15 01:28:48
複人数開発でインデントにうるさいのは当たり前だろ。
コーディング規約なんだから。
717:デフォルトの名無しさん
07/10/15 01:54:18
インデントなんか IDE が勝手にするだろ。
保存時に規約に沿うように自動フォーマット。
気にすんのはエディタ使ってるおっさんだけだ。
718:デフォルトの名無しさん
07/10/15 11:38:51
改行位置は勝手にやってくれなくないか？
719:デフォルトの名無しさん
07/10/15 11:50:20
今時のIDEならやってくれなくなくない？
720:デフォルトの名無しさん
07/10/15 12:53:26
Eclipse使えば自動フォーマットもすごいカスタマイズできるよ。
改行の位置も、(俺はコードの単位を明示的に分けたいから有効にはしないけど）
設定すればできる、と思う。
721:デフォルトの名無しさん
07/10/15 16:43:38
既にインデントは「する」ものじゃなくて「される」ものだろ。
人間がやるのは、内容の記述だけで、その整形は完全にIDEまかせ。
でも、eclipseできれいにインデントできないって理由で、仮引数へのアノテーションをためらう本末転倒な俺ガイル
722:デフォルトの名無しさん
07/10/15 17:03:49
細かい事気にしすぎ。
723:デフォルトの名無しさん
07/10/15 17:35:52
>>721
見やすさのためのインデントはそれでいいんだけど、
Pythonのようなインデント自体が括弧の役割をする言語ではまた別の話だよね。
724:デフォルトの名無しさん
07/10/15 17:38:12
人の書いたプログラムなど見ないで済むように偉くなれ。
725:デフォルトの名無しさん
07/10/15 17:39:06
>>723
とは言っても、Pythonでも見やすいインデント、というのはあるわけで。
726:デフォルトの名無しさん
07/10/15 18:05:18
ト・コ・ロ・デ
JDK7 build22
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
SwingWorkerのスレッドプールを使う処理が書き直されたらしい。
シャットダウンフックを使うようになったとかなんとか。
727:デフォルトの名無しさん
07/10/15 18:40:16
Javaは原則フリースタイル系統の言語だし、インデントはどうでもいいと思うが？
コーディング規約が別にあるとかいうならそれに従うまでだし。
728:デフォルトの名無しさん
07/10/15 20:45:32
Cとかに比べれば相当コーディング規約はしっかりしてると思うが
729:デフォルトの名無しさん
07/10/15 21:48:21
しっかりしているのは認めるが、しかしそれは言語仕様ではない。
インデントも含めて、コーディング規約も次世代に入れて欲しいと願っているのだろうか。
730:デフォルトの名無しさん
07/10/16 01:17:12
>シャットダウンフックを使うようになったとかなんとか。
使い方によってはwinでコケまくりだな。
昔よくフォーラムで流れたjavawからシャットダウンフックが起動しないってのが復活するんじゃない？