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からシャットダウンフックが起動しないってのが復活するんじゃない？
731:デフォルトの名無しさん
07/10/16 03:00:16
>>729
そこまですると、やり過ぎではなかろうかと思う。
俺はとりあえず括弧とif, for, whileの書式さえ統一されてればいいと考えてる。
732:デフォルトの名無しさん
07/10/16 03:16:45
まあもういいんじゃないか。そのコーディングとらやの話は。
733:デフォルトの名無しさん
07/10/16 10:56:12
20年以上前、ACM SIGPLAN Noticeでも、
インデントの話は禁止になったことがある。
734:デフォルトの名無しさん
07/10/16 14:07:05
↓↓↓次世代Javaの動向↓↓↓
735:デフォルトの名無しさん
07/10/16 14:11:07
命名規則とインデントはどうやっても宗教戦争になっちゃうからね。
736:デフォルトの名無しさん
07/10/16 17:12:35
まあもういいんじゃないか。そのコーディング虎屋の話は。
737:デフォルトの名無しさん
07/10/16 21:26:53
コーディングとらやの羊羹
738:デフォルトの名無しさん
07/10/16 21:53:01
とらやの話か。
739:デフォルトの名無しさん
07/10/17 01:35:40
虎屋の話と聞いて飛んできますた。
740:デフォルトの名無しさん
07/10/17 01:51:43
どうしてこうも人は争いの種を作ってしまうんだろうか
741:デフォルトの名無しさん
07/10/17 01:56:03
Javaの世界なのにJava以外の前提（CやC＋＋）を持ち出したのが原因。
742:デフォルトの名無しさん
07/10/17 01:58:35
人は人、自分は自分。偉い人には分からないのです。
743:デフォルトの名無しさん
07/10/17 02:23:48
誰もC/C++の話はしてないが
744:デフォルトの名無しさん
07/10/17 02:37:55
で、次世代はどーくるわけよ？
745:デフォルトの名無しさん
07/10/17 05:04:25
>>742 偉い人には分かるんじゃないか？ん？
746:デフォルトの名無しさん
07/10/17 07:58:18
俺はJavaの標準コーディング規約には満足してるけどな。
C#の、先頭を大文字にする記法や、プライベートフィールドの先頭にアンダーバーを付ける記法に比べれば、
よっぽどスマートだよ。
747:デフォルトの名無しさん
07/10/17 08:49:20
Rubyを侮辱するのは止めてください。
748:デフォルトの名無しさん
07/10/17 11:36:31
ﾜﾛﾀ、Rubyのコーディング規約はそうなってるのかｗ
749:デフォルトの名無しさん
07/10/17 12:23:57
規約でなく、言語仕様だね。@で始まるとメンバフィールドになる。
750:デフォルトの名無しさん
07/10/17 13:07:54
大文字で始まるとimmutable。> Ruby
751:デフォルトの名無しさん
07/10/17 15:10:32
C#はVCと同じくMSのキモサモサが良く出ている言語だと思う
752:デフォルトの名無しさん
07/10/17 16:05:50
C#で画面を作るとコントロールを描画している過程が見えるからなぁ
753:デフォルトの名無しさん
07/10/17 16:13:23
C#出たころからｺﾞﾃｺﾞﾃとJavaにいろんな機能がつき始めたよな
754:デフォルトの名無しさん
07/10/17 16:16:12
最近のJavaは美しくないというか崩れてきてる感があるな
755:デフォルトの名無しさん
07/10/17 16:21:23
genericsとannotation(とprintf)くらいで十分だったのにな
静的型言語でgenericsなしとかﾊﾞｶじゃないかと思ってたが今はいらんのつけすぎ
756:デフォルトの名無しさん
07/10/17 16:38:36
まぁでも早くC#に追いついて欲しいとは思うし難しいところだ
757:デフォルトの名無しさん
07/10/17 16:38:40
>>754 具体的にどこ？
>>755 といっても数年後にはクロージャとかenumとか使うようになるよ。
758:デフォルトの名無しさん
07/10/17 17:27:17
今だに使われるFORTRAN77は不滅だよ
759:デフォルトの名無しさん
07/10/17 17:32:40
>>754
なんとなくだがいいたいことはわかる。初期の頃の簡潔さは失われつつあるからな。
それでも、頻繁にクロージャ用無名クラスを作ってるようなら、クロージャを導入する意味はあると思う。
760:デフォルトの名無しさん
07/10/17 19:16:44
クロージャは必須だろ。
プロパティは辞めて欲しいが。
761:デフォルトの名無しさん
07/10/17 20:38:25
プロパティを作ってほしいとも思うが、セッターゲッターと互換性のないプロパティ作られるのも困る
762:デフォルトの名無しさん
07/10/17 22:15:11
セッターゲッターと互換性あるプロパティって何？？？
763:デフォルトの名無しさん
07/10/17 22:20:36
obj.property = value; が obj.setProperty(value); に、
value = obj.property; が value = obj.getProperty(); に、
展開されるような構文糖プロパティの事じゃね？
764:デフォルトの名無しさん
07/10/17 22:31:18
バージョンアップする限りJavaは肥大し続ける。
Java自体が陳腐化するか、
言語として互換性を捨て新たな言語に生まれかわらないとな。
765:デフォルトの名無しさん
07/10/17 22:39:36
どれだけ互換性捨てるかにもよるけど、新たな言語に生まれ変わらせるぐらいなら
Javaを捨てて、JVM用の新言語を立ち上げた方が既存のプログラムに影響少ないし
過去のしがらみ捨ててドラスティックに変えられるしで、良いと思うがね。
766:デフォルトの名無しさん
07/10/17 22:47:09
それはまだとっておこう。
767:デフォルトの名無しさん
07/10/17 22:49:25
新たな言語になったって、
バージョンアップのたびに肥大化し続けるのは変わらんだろうし、
時間が経つにつれ陳腐化するのは止められないだろうし。
768:デフォルトの名無しさん
07/10/17 23:10:19
Javaのクロージャで拘束変数の扱いはどうするつもりだろ？
楽なのは匿名クラスと同じでstatic finalな定数だけにするか、
拘束変数は必ずコピーにする方法なのだけど。
769:デフォルトの名無しさん
07/10/17 23:37:14
草案によって違う。
本命っぽい BGGA だと、
URLﾘﾝｸ(www.javac.info) の 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だと、URLﾘﾝｸ(docs.google.com)
の III. Local Variables From the Enclosing Scope あたり、
FCM だと、URLﾘﾝｸ(docs.google.com)
B. Common rules and mechanisms にある
> Local variables from the enclosing scope may be accessed, both read and write
770:デフォルトの名無しさん
07/10/17 23:51:32
BGGA だと、受け取り側が java.lang.RestrictedFunction しかうけとらねーよと明示しておけば、
final がついてない局所変数使ってるクロージャリテラルは変換できなくてコンパイルエラーになる
とか、そーゆー制限も考えられてるみたいだけど。
771:デフォルトの名無しさん
07/10/18 02:47:35
レキシカルクロージャがいいな。
javaはVMも言語もクラスファイル仕様も互換性確保は相当なものだが、ライブラリ詰め込みすぎが悪い。
#rubyは言語界のモルモン教
772:デフォルトの名無しさん
07/10/18 03:08:54
どの辺りがモルモンしてる？
773:デフォルトの名無しさん
07/10/18 11:08:02
製作者がモルモン教徒
774:デフォルトの名無しさん
07/10/18 18:24:15
というかruby信者がモルモン信者と同じ臭いがする。
775:デフォルトの名無しさん
07/10/18 20:37:37
Macユーザーで、はてなユーザーで、rubyユーザーでケータイがMEDIA SKINあたりだったら、
もう半径5mには入りたくない感じ。
聞きたくもない長所の押し売りをえんえんと聞かされそう。
776:デフォルトの名無しさん
07/10/18 20:49:07
それ、なんて宗教？
777:デフォルトの名無しさん
07/10/18 21:13:55
>>775
プログラマーはあんましMAC使わないとおもうんだが。
778:デフォルトの名無しさん
07/10/18 21:16:36
MacもWindowsも使う。
どれかしか使わないというのが、言語論争と同じく不毛な流れかな？
javaもrubyもperlもpythonも適材適所に使えばいいじゃない
779:デフォルトの名無しさん
07/10/18 21:45:47
>>778
たしかに其れが一番かっこいい。
780:デフォルトの名無しさん
07/10/18 21:59:27
rubyはperlとpythonのパラダイムに影響受けてるからそっちの分野に食い込んでくるんだよ無理やり。
rubyの影響を受けたGroovyは言語が止まってるから問題ないが。
結局、JRubyとGroovyとJythonはScripting APIに組み込まれるのかね？
要らん気がする・・・。
781:デフォルトの名無しさん
07/10/18 23:46:52
JavaFXは偉大
782:デフォルトの名無しさん
07/10/18 23:47:28
なにが？
783:デフォルトの名無しさん
07/10/19 00:04:32
手元にあればmac使いたけどな。
だけどwinの方が安いからmac使う機会がないだけ。
784:デフォルトの名無しさん
07/10/19 00:13:40
普通にlinux使えよ
785:デフォルトの名無しさん
07/10/19 00:16:36
linuxは普通なのか？
786:デフォルトの名無しさん
07/10/19 00:58:05
MacメインでWindowsも使うJava好きのモルモン信者ですが、何か？
787:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/10/19 01:46:49
アホ。釣られんな。
789:デフォルトの名無しさん
07/10/19 02:05:16
>>777
君、アタマ悪イッショ。
オンモ二デテミ。
君ノ馬鹿サガ…
790:デフォルトの名無しさん
07/10/19 02:54:19
アホ。釣られんな。
791:デフォルトの名無しさん
07/10/19 09:53:36
モルモンっていうと家畜の内臓がどうしても思い浮かぶ
792:デフォルトの名無しさん
07/10/19 23:47:33
未だに1.6が出てなかったのか…＞Mac
793:デフォルトの名無しさん
07/10/20 00:26:03
酷い話でしょ？コミュニティに任せた方がいいような気がするよ。
794:デフォルトの名無しさん
07/10/20 00:34:37
MacでJavaってそんなに使われてる？
795:デフォルトの名無しさん
07/10/20 00:46:49
V2Cを動かすのに必須。
これが無くなるとMacを捨てなくては・・・とまでいう重要ソフト。
796:デフォルトの名無しさん
07/10/20 01:00:03
fx＋bbs2chreaderでいいじゃない
797:デフォルトの名無しさん
07/10/20 01:04:06
icedteaだっけ？フリー版のないのか
798:デフォルトの名無しさん
07/10/20 01:06:55
Java SE 6 Update N
URLﾘﾝｸ(jdk6.dev.java.net)
ブラウザプラグインの書き直し
URLﾘﾝｸ(ajaxian.com)
この辺りの改良でクライアントサイドの勢いがついてほしい所だな。
799:デフォルトの名無しさん
07/10/20 11:18:05
java6のSwingは、結構Windowsのクライアントサイドでも戦える形になってきたかなと思う。
5と6での差異なんて、数ドット単位のデザインの違いが主なんだけど、その数ドットの差が大きい。
あとはスプリットボタン、シェブロンあたりのウィジェットが追加されればなー。
800:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/10/21 01:14:37
このJVMは独自のプロセスでも動くので、
JVMがクラッシュしたとしてもブラウザには影響を与えません。
そんなに変か？
802:デフォルトの名無しさん
07/10/21 10:03:06
今まで、さんざんブラウザを巻き沿いにしてきたみたいだよなw
803:デフォルトの名無しさん
07/10/21 10:18:23
巻き添えっていうか、一気に重くなってその負荷で落ちたように見えることは多かったけど。
ブラウザとは別のプロセスで実行できるってセキュリティ的に大丈夫なんだろうか。
ただでさえVistaでUACとかいうややこしいシステムをとってるのに。
804:デフォルトの名無しさん
07/10/21 10:27:36
↑大丈夫だからやったんじゃないかね
805:デフォルトの名無しさん
07/10/21 11:47:14
>>803
まずくなる理由が見つからんが…
806:デフォルトの名無しさん
07/10/21 12:25:31
>>803
Javaアプレットは、なぜネットワークからダウンロードしてきたコードを実行しても
安全なのか知りたければ、「バイトコードベリファイア」「サンドボックスシステム」
について調べてみるといい。
そうすれば、別プロセスで動作させても安全な理由がわかる。
807:デフォルトの名無しさん
07/10/21 12:27:37
>>805
Vistaで導入された鬱陶しい機能の一つに、UACとかいうのがある。
これは、セキュリティ対策のために、ブラウザの権限を制限するもんだ。
だから、ブラウザ上から呼び出されたプロセスには、なにかと制限がかかる可能性がある。
特に、ローカルのリソースにアクセスするようなのは、実行できないかもしれない。
まあ、>>804のいうようにわかってやってるはずだから、対策がないわけがないんだけどね。
808:デフォルトの名無しさん
07/10/21 17:03:53
>>807
>Vistaで導入された鬱陶しい機能の一つに、UACとかいうのがある。
>これは、セキュリティ対策のために、ブラウザの権限を制限するもんだ。
それはIE7の「保護モード」であって、UACではない。
809:デフォルトの名無しさん
07/10/21 18:32:03
>>808
そうだった。
今思い浮かんだんだが、もしかして保護モードを回避するために別プロセスに分けたのか？
だとしたら、俺が言ってたことはまるで逆だったのか。
810:デフォルトの名無しさん
07/10/21 19:18:12
↑だからここは君の浅知恵を披露する場ではないようだが
811:デフォルトの名無しさん
07/10/21 20:14:23
なんで次世代Javaスレに猿が混じっているのか不思議
812:デフォルトの名無しさん
07/10/22 10:35:00
↑猿の脳みそを持つ男
813:デフォルトの名無しさん
07/10/22 11:58:57
↓ご立派な人登場。
814:デフォルトの名無しさん
07/10/22 14:32:22
呼んだ？
815:デフォルトの名無しさん
07/10/22 16:23:51
おいおい、俺を差し置いてか？
ゴスリンが、JDK on Mac OS Xについて少し喋ってる。
URLﾘﾝｸ(blogs.sun.com)
816:デフォルトの名無しさん
07/10/22 16:52:06
イヤ待て、もっと大変な事言ってないか？
オレには、MacOSXにZonesが載るって書いてるようにも読めるぞ。
流れ的にそう明言してないが・・・
817:デフォルトの名無しさん
07/10/22 18:52:08
>>816
Zonesってなに？
818:デフォルトの名無しさん
07/10/22 18:59:43
スレ違いだが、
Solaris:BSD:Linux≒Zones:Jail:Vserver
819:デフォルトの名無しさん
07/10/22 22:37:44
ｚ
820:デフォルトの名無しさん
07/10/23 04:27:30
sunはJava SEの後につく数字をマイナーバージョンとリンクさせているように見えるけど、
メジャーバージョンが上がる時にはどうするつもりなんだろう。
Java 2 SEとかにするのかな
821:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/10/23 08:57:17
>>820
Java 2 Platform, Standar Editionとかぶりすぎ
>>821
そういうマイナーバージョンの桁上がりの問題じゃないからw
823:デフォルトの名無しさん
07/10/23 10:17:44
メジャーバージョンが上がるときの対策
・Javaのあとに新しいバージョンだとわかるようなコード・名前・別名をつける
・Java自体の名前がかわる
・何事もなかったかのようにバージョン表記統一
824:デフォルトの名無しさん
07/10/23 14:30:33
>>821
前にlinuxのソフトウェアでndiswrapperっていうのを使ってたんだが、
使用してるバージョンが1.7で、最新のバージョンが1.21だったのを1.2.1だと勘違いして
なんでバージョンダウンしてるのかすごい悩んだことがある。
825:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/10/31 19:07:24
JDK7 build23
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
なんか今回は実質的な進捗なさげだな。
「ソースのスペースを掃除したよ」って。
なんか行き詰まってるときの作業だろ。
でも2週間に1ビルドのペースが出てきたのは評価したい。
827:デフォルトの名無しさん
07/10/31 21:05:23
クロージャのプロトタイプ発表とかどうとかは、どうだった？
828:デフォルトの名無しさん
07/11/09 23:07:29
クラス注釈に@RAIIとかサポートされたらいいな。
必ずスタックに乗るように解釈させて、スコープ抜けると必ずfinalizeされる。
メンバ内も含めてthisが代入または引数にされた場合は、コンパイルエラーとするとか。
829:デフォルトの名無しさん
07/11/09 23:20:54
７は5よりもいろいろと、てこもりで楽しみだな。
830:デフォルトの名無しさん
07/11/10 01:50:16
>>828
C言語のregisterとかと同じで、最初のうちは最適化義務はなく将来対応するとか言っておいて、
そのうち最適化が進化したので必要ないから無視するよってなるような気もする。
831:デフォルトの名無しさん
07/11/10 05:06:57
なんかもうJavaはIDE前提の言語として突き進んでほしいなあ。
言語仕様もとにかくIDEでサポートしやすい方向で。
832:デフォルトの名無しさん
07/11/10 09:24:07
>>828
finalizeされるタイミングを陽に指定できることは除いて、
今やescape解析の仕事です。
そんな時代遅れなものが入るわけがない。
>>831
馬鹿丸出し。
833:デフォルトの名無しさん
07/11/10 11:27:07
>>832
ゴスリングのこの発言があったタイミングで
バカ丸出しと脊髄反射するほうがバカ丸出し
URLﾘﾝｸ(www.atmarkit.co.jp)
834:デフォルトの名無しさん
07/11/10 11:50:46
そんなの知ってるw
その解釈こそ馬鹿丸出しじゃん。
IDEで出来ることは、IDEでやればいいんだから。
言語を糞仕様にする必要はない。
835:デフォルトの名無しさん
07/11/10 13:04:43
>>194
Jakarta JJarのことか？
MavenにもJJarは同梱されているんだが
836:デフォルトの名無しさん
07/11/10 13:19:03
SunはSolaris向けのIPSを発表したしなあ。
URLﾘﾝｸ(opensolaris.org)
最近、言語ごとにパッケージ管理/配布システムがあって困惑気味です。
837:デフォルトの名無しさん
07/11/10 19:31:56
ここにはエスケープ解析を研究してる奴いるから聞きたいことあれば聞いとけ。
838:デフォルトの名無しさん
07/11/10 20:58:50
Googleで検索すればすぐでてくる内容しか書かれてないのに研究だと？
839:デフォルトの名無しさん
07/11/11 06:30:11
クロージャの演算子 => , {int=>int}は他のなかったのかな？もう決定ぽいけど。
{int x=>x+1}とかぱっと見どうかと
840:デフォルトの名無しさん
07/11/12 15:07:20
lambda見なれてしまったから、他はなんでも違和感がある。
だからどうでもいい感じ。lambdaキーワードはあり得ないし。
Haskellみたいに\ってのもどうかと思うしさ。
841:デフォルトの名無しさん
07/11/12 23:40:09
>>839
1.5がでるときにGenerics見て、こんなのJavaじゃねぇって書き込みがいくつかあったよな
今、そんなこと言ってる奴いないだろう。慣れればそれが普通に見えてくるはず
842:デフォルトの名無しさん
07/11/13 00:10:57
プロパティのアクセス演算子は
c->p=x
x=c->p
で決定なのか？
843:デフォルトの名無しさん
07/11/13 00:40:12
>>842
いつの情報だ、それは。
844:デフォルトの名無しさん
07/11/13 01:03:03
結局Javaっていっても現状Web用途がメインなんだから
Servlet&JSPのほうがもっと良くなってほしい。
JSPがダメすぎてどうにもならない。
845:デフォルトの名無しさん
07/11/13 01:08:22
JSP、JSF、VelocityServlet、Wicket・・・好きなもの使え。
846:デフォルトの名無しさん
07/11/13 01:10:41
>>844
ここはSEのスレなんだよ。
そんな呆けだから(ry
847:デフォルトの名無しさん
07/11/13 01:36:26
>>843
え、古かった？
じゃ、今はなんだよ
848:デフォルトの名無しさん
07/11/13 02:20:28
>>846
ていうか標準のView仕様くらいもうSEに含めろっちゅう話やねん。
JSPにしても単なる条件分岐記述するのに別ライブラリダウンロードさせるってどないやねんって話やねん。
スクリプティングサポートする暇あったらテンプレートエンジンサポートしたほうが人気出るねん。
849:デフォルトの名無しさん
07/11/13 02:29:59
スクリプトレットの存在も知らなければ
テンプレートエンジンはスクリプトエンジンのひとつに過ぎないという実態も知らないのか？
テンプレートエンジンなんぞとっくにサポートされてるっての
850:デフォルトの名無しさん
07/11/13 02:39:48
>>849
おい、JSP2.1の時代にスクリプトレット使ってんのかよ・・・
851:デフォルトの名無しさん
07/11/13 02:41:43
お前が使いたいだけだろ、お前って御託だけで使い分けもできないのな
852:デフォルトの名無しさん
07/11/13 02:45:42
Java系の開発者って世の中のニーズが読めないやつばっかだよな・・・
853:デフォルトの名無しさん
07/11/13 02:51:53
典型的なかまってちゃんだな、JCPのこと調べたらJavaは諦めてPHPでもやっとけ
854:デフォルトの名無しさん
07/11/13 02:59:26
どっちにしろDerbyなんかSEに組み込むより、Viewのほうが先だろ・・・常識的に考えて・・・
855:デフォルトの名無しさん
07/11/13 03:01:41
かまってちゃんとわがままちゃんって同じ匂いがするんだよな。２ｃｈの経験上
856:デフォルトの名無しさん
07/11/13 04:23:08
>>848
頭悪～
Web制作板に行きなよ。
このスレはまだ早いよ。
857:デフォルトの名無しさん
07/11/13 15:25:07
>>82
これには何かぐっと来たぞ
858:デフォルトの名無しさん
07/11/15 01:06:38
>>854
ViewならSwingがあるじゃねぇか。
859:デフォルトの名無しさん
07/11/15 01:08:16
お前らこれ以上XSLTさんを泣かすな
名実ともにSEのViewだろ
860:デフォルトの名無しさん
07/11/16 18:41:58
名実が伴っているなら泣くこともないだろうw
861:デフォルトの名無しさん
07/11/23 18:53:57
Extension Methods とか出てる。
URLﾘﾝｸ(gafter.blogspot.com)
どうなんだろ？ 嬉しい事は嬉しいけど、これって名前空間汚れるような。
これが許されるなら、クロージャも closure.invoke(argument);
じゃなくて closure(argument); したい。
862:デフォルトの名無しさん
07/11/23 19:04:27
D言語にある機能だってのは知ってるけど、この機能の初出って何だろうね
863:デフォルトの名無しさん
07/11/23 19:14:58
そう書くことで綺麗に気持ちよく書けるものはどれくらいあるのかね
864:デフォルトの名無しさん
07/11/23 19:27:54
>>863
java.util.List みたいな published interface にメソッド追加するのが主な目的ってのはいわずもがなだけど。
他の使い道ってなんかあるかね？
865:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/11/23 20:02:23
>>865
char[] はともかくとして、String も StringBuilder も StringBuffer も、
codePointCount や codePointAt を持ってるはずだぞ。
CharSequence で持ってないのって java.nio.CharBuffer ぐらいか？
867:デフォルトの名無しさん
07/11/23 20:02:25
こんなダサイの入れるくらいなら、
Haskellのtype classとかC++のconceptみたいな
generic programming支援の機構を入れて欲しいわ。
868:デフォルトの名無しさん
07/11/23 20:24:34
interfaceで扱う事に意味があるんじゃないの。例えばC#だけど
List<E>.ForEach(delegate(E)) みたいなのがあるけど、IList<E>じゃ使えなくて困惑したことがある。
重複したときはエラーかオリジナルのオーバーロードどちらを優先するんだろう。
interfaceのままでもリフレクションで解決とかもいいけど、それは遅くなるか。
869:デフォルトの名無しさん
07/11/23 20:35:45
>>868
それは published interface の話じゃなくて？
そーいや、C# は 3.0 で extension method 入るんじゃなかったか？
870:デフォルトの名無しさん
07/11/23 20:59:46
static importはIDEと相性が悪い印象があってあまり使われてないけど
これが導入されたらIDEに第一引数でサーチいかせる感じで使われ出すんじゃないかな。
871:デフォルトの名無しさん
07/11/23 21:29:37
やっぱpublished interfaceにメソッド追加（したように見せかける）以外に使い道ないんじゃ？
872:デフォルトの名無しさん
07/11/23 21:56:47
内部構造はまったくいじれないしな
873:デフォルトの名無しさん
07/11/25 22:09:42
Javaってプライドとかないの？
874:デフォルトの名無しさん
07/11/25 22:19:37
URLﾘﾝｸ(java.sun.com)
無いね。Java7 でもきっと無い。
875:デフォルトの名無しさん
07/11/25 22:19:46
Javaのプライドって何のプライドよ？
876:デフォルトの名無しさん
07/11/25 23:24:42
言語としてのプライド
877:デフォルトの名無しさん
07/11/25 23:27:34
なんかアホの子が出現してるな
878:デフォルトの名無しさん
07/11/26 11:50:05
>>861
> これって名前空間汚れるような。
その点、リンク張られているExpanderの方がまだいいね。
879:デフォルトの名無しさん
07/11/26 13:59:55
>>875
Java使いが集まって、大晦日に闘う。
880:デフォルトの名無しさん
07/11/26 14:17:23
Gosling緊急参戦！
とかなら見に行く。
881:デフォルトの名無しさん
07/11/26 14:50:30
>>879
冗談としては面白くないけど
本当にやったら面白そうだな、それ。
882:デフォルトの名無しさん
07/11/26 17:48:38
>>881
想像したらわろた
883:デフォルトの名無しさん
07/11/26 18:07:02
>>879
何で戦うんだよwwwコーディングかwww
884:デフォルトの名無しさん
07/11/26 19:52:13
JavaOne Tokyoのときみたいに、プロレス
885:デフォルトの名無しさん
07/11/26 22:05:45
そうね、ここはコーディングでといいたいところを
ぐっとこらえて、総合ルールでやってもらった方が
盛り上がるね！
886:デフォルトの名無しさん
07/11/26 23:12:33
じゃあ多重継承もfriendも属性も継続もありでいいんだな。
887:デフォルトの名無しさん
07/11/26 23:14:37
属性って？ annotation じゃダメなん？
888:デフォルトの名無しさん
07/11/27 10:35:10
>>880
Goslingが和太鼓たたきながら、
「本物のプログラマでてこいや！」
889:デフォルトの名無しさん
07/11/27 11:18:22
本物のプログラマはPascalを使わない――Javaも使わない。きっと。
890:デフォルトの名無しさん
07/11/27 18:39:40
本物のプログラマだなんてガキみたいなこと言ってるうちは、
その本物のプログラマなるものにはなれんだろうな
891:デフォルトの名無しさん
07/11/27 18:57:17
何を使うんだろう。やっぱりLisp？
892:デフォルトの名無しさん
07/11/27 19:37:41
>>890
本物のプログラマネタくらいは知っておこうぜ、本物のプログラマならｗ
ググればすぐに出てくるよ
893:デフォルトの名無しさん
07/11/27 19:37:47
ホンモノのプログラマになる極意は、ホンモノの真似をしないことである
894:デフォルトの名無しさん
07/11/28 17:06:57
ふるいネタだな。キッシュを食わないとかいうヤツだっけ。
895:デフォルトの名無しさん
07/11/28 22:21:39
ホンモノのプログラマはデスマーチで2chに書く暇などありません。
偽者の人生が楽しい
896:デフォルトの名無しさん
07/11/28 23:07:44
業務が設計中心になってからはデスマはないなぁ。
設計工程に現役プログラマが携わらないことの危険性が
頭でもなく心でもなく体で理解したｗ
897:デフォルトの名無しさん
07/11/29 01:38:43
よほどヘボいSEとやってたんだな。
898:デフォルトの名無しさん
07/11/29 13:16:30
プログラマーは設計書が全然上がってこねーぞと文句を言っているはず
デスマの原因作ってるのはお前だｗ
899:デフォルトの名無しさん
07/11/29 21:09:42
↑こいつ文盲？
900:デフォルトの名無しさん
07/11/29 21:13:46
うん
901:デフォルトの名無しさん
07/11/29 22:11:53
宣言側の拡張メソッドだってさ。
URLﾘﾝｸ(digital-sushi.org)
ユーザ側で拡張すると、メソッド名の衝突とか面倒くさいって話らしいけど。
902:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/11/30 01:37:50
曖昧な場合はコンパイルエラーになるだけ
904:デフォルトの名無しさん
07/11/30 02:11:30
>>901
馬鹿馬鹿しい…
905:デフォルトの名無しさん
07/11/30 02:20:12
>>903
いや、use-site でも declaration-site でも曖昧なケースが出てくるのは同じじゃねーかって話。
906:デフォルトの名無しさん
07/11/30 22:05:42
LINQのような糖構文がほしい・・・
やっぱいらない
907:デフォルトの名無しさん
07/11/30 23:13:41
ハイバーネートだかなんだかのO/R マッピング使ったらええんとちゃう？
俺もLINQはいらんけど、varはほしいな。
908:デフォルトの名無しさん
07/12/07 14:03:49
JDK7 build24
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
あれ？変更点からっぽ？
909:デフォルトの名無しさん
07/12/07 16:32:16
>>906
今更だが、糖衣構文を糖構文とは略しないでしょ。
910:デフォルトの名無しさん
07/12/07 17:05:48
syntax sugarを糖構文と訳すのはアリだと思うが。
911:デフォルトの名無しさん
07/12/07 17:08:07
>>910
マジすか・・・。略語じゃなくて訳の違いだったわけか。
912:デフォルトの名無しさん
07/12/07 18:35:49
「糖衣構文」 と 「構文糖」 は聞いたことあるけど 「糖構文」 はあまりないな。
913:デフォルトの名無しさん
07/12/07 18:35:52
>>910
うーん、それはやめた方がいいと思う。
糖衣構文がうざければ、シンタックス・シュガーでいいし。
914:デフォルトの名無しさん
07/12/07 21:23:36
>>908
JDK6u3と比べて、アプリケーションのメモリ消費量が減っているような気がする。
915:デフォルトの名無しさん
07/12/11 01:19:49
Java SE 6 Update N Early Access build 08キタ。新しいJava Plug-Inが入った模様。
JDK 6u10 build b08
URLﾘﾝｸ(jdk6.dev.java.net)
URLﾘﾝｸ(download.java.net)
916:デフォルトの名無しさん
07/12/11 13:13:20
>>908
b23 と b24 は TeamWare から Mercurial にリポジトリを移動しただけで、全く同じものらしい。
URLﾘﾝｸ(weblogs.java.net)
フォーラムで出てた。
URLﾘﾝｸ(forums.java.net)
917:デフォルトの名無しさん
07/12/11 13:17:01
>>905
あれって use-site でというか、static import で use-site extension methods やると
既存の static import 使ってるコードで問題出るかもって話じゃないの？
918:デフォルトの名無しさん
07/12/11 13:56:19
>>916
ナルホド。開発者の使ってる環境が知りたいな。GUI無しかな？
Teamwareとコマンドラインの体系は似てるし、CUIベースでかな？
それとも開発者は、Netbeans使ってるから最近出てきたMercurialのプラグイン使ってる？
919:デフォルトの名無しさん
07/12/21 12:17:34
まだ草案レベルにもなってない例外関連のアイデアらしい
URLﾘﾝｸ(www.javac.info)
URLﾘﾝｸ(www.javac.info)
multicatchは欲しい。
multicatchがあれば、rethrownはいらないような気もする。
920:デフォルトの名無しさん
07/12/21 12:32:25
"Exception1 | Exception2" って型ができるのかとおもうと、おらわくわくして（ｒｙ
型とか安全なのかな。とりあえず実現できなくはないと思うけど。
921:デフォルトの名無しさん
07/12/21 12:47:57
基本的には「複数の catch節をくっつける」ってアイデアで
型安全どーするの？ とかの問題は先送りされてるんじゃね？
Exception1 | Exception2 って型も共通の親クラスのメソッドしか
呼べないんじゃないかと思ってる。下手にcatch節以外でも
Exception1 | Exception2って型が使いたいとか騒ぐと、
仕様考える連中が面倒になってポシャるんじゃないかなとか思ったり思わなかったり。
っつーか、Rethrown はその辺が面倒になったから出てきたアイデアなんじゃ？
922:デフォルトの名無しさん
07/12/21 16:49:50
catch(Exception1 | Exception2 ex) { ex.Foo(); }
から
catch(Exception1 ex) { ex.Foo(); }
catch(Exception2 ex) { ex.Foo(); }
は機械的に作れるから、まあ何とかなるんじゃない？
923:デフォルトの名無しさん
07/12/21 17:24:21
複数の例外型について handler_pc の位置を共通にするようにするんかと思ってた。
VM仕様で handler_pc はユニークにしろ、とかって制約ついてたっけ？
924:デフォルトの名無しさん
07/12/23 21:24:10
ConcurrentHashMap<CustomKey<Exception, Handler>, Executor<Runnable>> とかすればいいと思うよ。
925:デフォルトの名無しさん
07/12/29 10:41:26
URLﾘﾝｸ(www.infoq.com)
クロージャ入れるのも一苦労じゃ
926:デフォルトの名無しさん
07/12/29 11:01:42
おれクロージャいらねぇ派だがどうせ新機能入れるなら個人的には多値返却かAda風の型定義がほしいかな。
927:デフォルトの名無しさん
07/12/29 12:01:37
皆でScalaへGO!
928:デフォルトの名無しさん
07/12/29 12:28:15
そーいや、ム板にscalaスレあったっけ？
929:デフォルトの名無しさん
07/12/30 00:05:55
C#3.0さわってみたが進化してるなあ。
lambda関数が int a => return a + 10 みたいな感じでインラインに書けたりと、
スクリプト言語ラブな人は嬉しい機能がどっさり。
思わず浮気しそうになる・・・。
930:デフォルトの名無しさん
07/12/30 00:22:31
>>929
> lambda関数が int a => return a + 10 みたいな感じでインラインに書けたりと、
これreturn要らないんじゃ？
BGGAのクロージャの構文、セミコロンがついたりつかなかったりで
局所リターン文だったり単なる式文だったりっつーのはバグの原因になりそうな。
ラムダ式っぽく使うならreturn書きたくないってのもわかるんだけど……
その点、C#の構文はよくできてると思う。
931:デフォルトの名無しさん
07/12/30 00:55:17
その程度ならecma262で十分。
932:デフォルトの名無しさん
07/12/30 01:05:59
>>930
それだけじゃなくて、C#3.0のラムダ式で int a みたいにパラメタ型を明示する場合はパラメータリストに括弧が必要なはず。
933:デフォルトの名無しさん
07/12/30 03:15:35
>>926
それだとクラスを返しても全く同じだけど、どう違いをみせたいわけ？
934:デフォルトの名無しさん
07/12/30 10:22:01
>>933
戻り値のためにクラスをわざわざ定義するのがめんどいんじゃね？
シンタックスシュガーとしてやってくれると、ちょっと便利かもね、と。
935:デフォルトの名無しさん
07/12/30 10:52:00
>>928
ちょっと前に探したときは見当たらなかった。
936:デフォルトの名無しさん
07/12/30 11:09:29
JVM系で残っているスレはこれだけだと思う。
Jython、Groovy、JRuby - どれが一番効率的？
ｽﾚﾘﾝｸ(tech板)
Java系スクリプト言語Groovy
ｽﾚﾘﾝｸ(tech板)
落ちないようにJVM系は統一して欲しいなあ。
Scalaは、Javaとの連携除いても、結構いい型システム持っているけど、
単独ではすぐに落ちちゃうと思う。
937:デフォルトの名無しさん
07/12/31 16:42:52
>>934
同じくタプルとかも賛成なんだけど、どうもそういうのはJavaぽくないみたい。
面倒だしとかじゃ「違う言語で」とかだから、だから「どう違いをみせたいわけ？」って聞いてる。
少なくとも君の要求ていどならわざわざ文法とか複雑にしなくとも、
Object[] func()
でこと足りるしｗ
938:デフォルトの名無しさん
07/12/31 16:58:01
多値用のGenericsを標準で用意してくれると嬉しいんだけどね。
こっちで用意してもいいけど、それ専用のjarってのもちょっとね。
939:デフォルトの名無しさん
07/12/31 18:28:14
前も出たなこの話題w
俺にいわせりゃ多値引数はあるのに多値返却がないのはおかしいんだけどな
クロージャとかの方が違う言語でやってほしいよ。javaがシンプルさとかけ離れていく
940:デフォルトの名無しさん
07/12/31 18:44:28
クロージャって匿名クラスで作るんだろ？
クロージャの生成側のローカル変数は、その時点で固定になるのかな？
941:デフォルトの名無しさん
07/12/31 19:08:51
>>940
そのやりかたが2つくらい出てきてどっちにするかまだ決まってなかったんじゃなかったっけ？
942:デフォルトの名無しさん
07/12/31 19:23:38
>>769 あたりか。
943:デフォルトの名無しさん
07/12/31 19:32:57
あら、割と近めにあったのね。すまんこつ。
944:デフォルトの名無しさん
07/12/31 19:35:51
可変長引数を多値引数って言うのは初めてみたかも。
945:デフォルトの名無しさん
07/12/31 20:18:52
可変長引数のこと言ってたのか。
946:デフォルトの名無しさん
07/12/31 20:21:18
たぶん。
いや、はじめてみた言葉だから間違ってるかも知らんけど。
947:デフォルトの名無しさん
07/12/31 20:32:39
すまん今作った＞多値引数
とっさに出てこなかったんだよ
948:デフォルトの名無しさん
07/12/31 20:39:13
オーバーロードのことじゃなくて？
949:デフォルトの名無しさん
07/12/31 20:44:29
単純に引数を複数渡せるってだけの話だろ
950:デフォルトの名無しさん
08/01/01 03:36:41
>>949が正解だろ。
単純に引数(インプット)には複数の値を渡せるのに、
返値(アウトプット)が一つしか返せないのはおかしい、という話。
そもそも、大元の関数型言語が(厳密には違うが)一入力一出力だったのを、
手続き型言語で使いやすいよう多入力にしたのが原因。
OOPの思想が確立したときに多出力にすればよかったのだが、折しもCベースのC++が主流だったのでそのまま。
またCPUの最適化の関係もあり、ずるずるとJava, C#・・・と今に至る。
もしJavaで多出力をサポートするなら、
rubyやpythonの返値の扱い（タプル関連)で、シンタックスシュガーが複雑になりすぎてる感があるので、(特にruby)
Javaが簡潔かつわかりやすい書式（もしくはタプルに代わる概念)を策定して欲しい、と思う。
951:デフォルトの名無しさん
08/01/01 10:04:29
単純に引数1個に制限すれば、対称になって>>950の気は済むってこと？
952:デフォルトの名無しさん
08/01/01 13:43:46
もはや return は継続の呼び出しで良くね？
953:デフォルトの名無しさん
08/01/02 13:56:26
＞Javaが簡潔かつわかりやすい書式（もしくはタプルに代わる概念)を策定して欲しい、と思う。
結局それかよ。それを策定するのが難しいからないんだろ！
おまえが考えて提案したらどうだ？当然英語はできるよな？
面倒って言うのが理由なら、あまり期待しないほうがいいじゃないか。
それと>>950はツッコミどころが多すぎだけど、
JavaはC++辺りと違って理念が実稼動重視（現実的)だから。
>>951もいいと思うよ。でも
Object[] func(Object[]);
で十分。JDK1.0 OK
有用であるが、使うかどうかは任意。
954:デフォルトの名無しさん
08/01/02 14:05:23
>>953書いて思ったけど、
というか普通にポインタ(C, C++)理解してるかってことに行き着くと思うよ。
本質的には、ポインタとかデータ構造とかそういうところ。
955:デフォルトの名無しさん
08/01/02 16:52:28
ポインタ関係ないな。
参照でいい。
956:デフォルトの名無しさん
08/01/02 17:21:18
It is assumed that many value return was realized by JAVA and on earth wants to do what?
957:デフォルトの名無しさん
08/01/02 19:02:07
新年早々とんだ釣りだw
958:デフォルトの名無しさん
08/01/02 19:15:55
そうするに偉そうなこといってる>>953はようやくポインタを理解したガキだってこと？
Object[]で戻していいが型の安全を言語側で保証できたらいいねって話なんだが
959:デフォルトの名無しさん
08/01/02 19:33:42
>>958
痛いおまえはｗｗ晒しあげｗｗ
960:デフォルトの名無しさん
08/01/02 19:42:24
また宗教ですか？
961:デフォルトの名無しさん
08/01/02 19:49:45
>>958
当然英語はできるよな？
962:958
08/01/02 19:59:22
おいおいなんだこれ('A`)
>JavaはC++辺りと違って理念が実稼動重視（現実的)だから。
>というか普通にポインタ(C, C++)理解してるかってことに行き着くと思うよ。
こういうのはスルーして俺に総ツッコミかよw
963:デフォルトの名無しさん
08/01/02 20:00:23
ストールマンのお友達ですか？
964:デフォルトの名無しさん
08/01/02 20:03:50
>>958
>>962
英語は当然できるんですか？
965:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/01/02 23:04:05
>>953
> それと>>950はツッコミどころが多すぎだけど、
> JavaはC++辺りと違って理念が実稼動重視（現実的)だから。
C言語のソースがそのままコンパイルできるC++を差し置いてJavaのどこが”実稼働重視(現実的)”なんだww
もしかしてC++をまったくさわったことがないんだろうか？
それと>>950のツッコミどころとやらを説明よろしくww
967:958
08/01/02 23:23:15
ああそういう話ね
>>613で出てるけどURLﾘﾝｸ(bugs.sun.com)で多値はwill not be fixedになってるのよ
で、その理由がjavaはシンプルであるべきだーと。
当然コメントには
ジェネリクスも加わったし昔のシンプルなjavaじゃないじゃん、とか
配列のシンタクスシュガーならJVMに変更いらないだろ、とか
可変引数があるのに戻り値が複数取れないのはおかしい、とかもうすでに散々出てるわけよ。
でそれを踏まえた上での>>939(俺)の
＞クロージャとかの方が違う言語でやってほしいよ。javaがシンプルさとかけ離れていく
だったわけよ
英語が堪能な>>953はそれを踏まえた上で
>結局それかよ。それを策定するのが難しいからないんだろ！
>おまえが考えて提案したらどうだ？当然英語はできるよな？
と言ってるんだよな？（>>950は俺じゃねーけど）
968:デフォルトの名無しさん
08/01/03 00:35:05
他でやれよもう。
969:デフォルトの名無しさん
08/01/03 01:59:17
苦労じゃのう
970:デフォルトの名無しさん
08/01/03 06:43:34
ストールマンじゃないです。
ゴズリンと友達です。
971:デフォルトの名無しさん
08/01/03 06:48:51
英語で会話できるようになるのは、日本人の夢なのです！
ジーニアス、ジーニアス！
972:デフォルトの名無しさん
08/01/03 06:51:34
>>966を読んでみても、相当痛いやつだなということだけは分かるw
30台は間違えないねｗ
この様子ならすぐ1000行くけど？どうする？やっちゃう？
973:デフォルトの名無しさん
08/01/03 07:30:05
>>962
>>966
おまえに勝ち目はないなｗ
そろそろ目を覚ませよｗ
974:デフォルトの名無しさん
08/01/03 07:40:36
馬鹿の方が声がでかいのは、ゴミ溜めではよくあること。
975:デフォルトの名無しさん
08/01/03 09:02:58
それをどうするかが問題なんじゃないか？
976:デフォルトの名無しさん
08/01/03 10:55:17
また宗教ですか？
977:デフォルトの名無しさん
08/01/03 11:32:48
英語は出来て当然です。
978:958
08/01/03 12:24:52
ごめんなさい勝ち目はありませんでした。
今目を覚ましました。