次世代Javaの動向　２

1 名前：デフォルトの名無しさん mailto:sage [2006/05/18(木) 01:03:42 ] 前スレ 【Java】次世代Java・J2SE1.6の動向【Mustang】 pc8.2ch.net/test/read.cgi/tech/1081698555/ 関連スレ 【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】 pc8.2ch.net/test/read.cgi/tech/1094891986/ www.itmedia.co.jp/news/articles/0404/07/news018.html マルチタスク実現へJava言語改良 Sun幹部によると、2005年に一般リリース予定の「J2SE 1.6」には、 Javaバーチャルマシン（JVM）のアプリケーション共有を強化する「分離」機能が備わり、 ローカライズコンピューティング処理実行のための分離が可能になるという。 米Sun Microsystemsは、Javaバーチャルマシン（JVM）内部での アプリケーションマルチタスク実現に向けてJava言語の改良に取り組んでいる。 カリフォルニア州サンノゼで開催のClusterWorld Conference & Expoで4月6日、同社幹部が明らかにした。 SunのJavaアーキテクト、ムラリ・カウンディンヤ氏によると、 今秋β版が登場し、2005年に一般リリース予定の「J2SE 1.6」には、 JVMのアプリケーション共有を強化する「分離」機能が備わる。 この機能によってローカライズコンピューティング処理実行のための分離が 可能になり、第2のJVMを要求することなくJVM内部でマルチタスクが行えるようになるという。 　またJ2SE 1.6では、Javaプログラム間の高速通信を可能にする Sockets Direct Protocolのサポートが計画されている。カウンディンヤ氏によると、 J2SEに施された改良は、その後間もなくJ2EEにも組み込まれる予定。 75 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 01:39:14 ] プロパティマンセー obj.setWidth(obj.getWidth() + 1)) なんて書かなくてもよくなりてぇえええ 76 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 04:15:52 ] じゃ、 obs.width = obj.width +1 ; になるわけか・・・・ なんか、VBのProcedureみたい。(VB4の知識で書いてます悪しからず) 77 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 06:14:57 ] >>75,76 ほんとにそうなるの？ おれはgetter/setterの定義を書かなくて済むようになるだけだと思ってた。 ソースきぼん。 78 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 08:33:46 ] >>77 むしろそっちがソースｷﾎﾞﾝ。 getter/setter だけなんて、中途半端じゃん。 79 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 09:09:56 ] >>78 いや、ソースはない。「プロパティがサポートされる」と聞いて、どうせgetter/setterが自動生成される程度で、getXxx()/setXxx()は使わないといけないのだろうと思った。それだけ。 80 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 13:25:01 ] >>79 getter/setterの定義よりも、それらにアクセスするコードを書く回数の方が 圧倒的に多いので、getter/setter自動生成だけだと、新しい言語機構を 導入するメリットが少なすぎる。だから、たぶんアクセスするときの便宜も 図られるんじゃないかなあ。 81 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 13:54:31 ] こんなんもいけるんかのう？ obs.width++; 82 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 15:16:13 ] >>78 ライトアクセスとリードアクセスを区別して grep できないのはやだなぁ。 83 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 18:35:27 ] >>82 呼び出し階層の検索でいけるんじゃないの？ たぶん。 あ、ごめん、これはEclipseの話だな。。。 84 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 23:12:33 ] とはいえピリオドでやっちまうとメンバ変数のwidthとgetWidthメソッドとの判断が難しいよな obs@widthとかobs->widthとかなんか特殊な構文が追加なのかも getsetかかせるよりはいいけどね 85 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 23:26:41 ] >>84 C/C++ で使われてる -> よりは @ に賛成。 Character.isJavaIdentifierStart('@') も false 返すみたいだし、 やろうと思えばできるのかな？ あと、JSR 295 見ると、converter や validator 使って何かやるみたいね？ obs@width = "120"; とかやると勝手に StringToIntegerConverter を 使ったコードを挿入してくれるのかな？ とか妄想してみる。 86 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 00:14:26 ] 245なんかのProperty Resolver APIが言語に入るんでしょ。 operator.のoverload。 Property Binding API, Method Biding APIなんかも。 87 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 11:49:33 ] >>80 Java��にそんな気の利いたことを望んではいけない。 ヒアドキュメントすらない言語だ、「互換性」を楯にして、最小限の使用追加だけですませるだろう。 しかしほんとに後付けの機能がふえるよな。もうぜんぜんシンプルな言語じゃなくなった。 88 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 11:58:45 ] プロパティに関しても1.1での後付考えかただし1.0はアルファ品質だったしな それでもプロパティはEODでは？ 用意するほうはIDEがやってくれるけど使うほうが原始的杉 Genericsは開発効率がよくなりバグが大幅に減るすばらしいものだが 落ちこぼれるやつが多数いる この程度でおちこぼれるのならそいつはこの業種向いてないとは思うのだが ひとつの判断材料にはなるかも lockはsynchronizedのように専用構文がないと厳しいような なんでもそうだが資源解法でfinallyあてにするのは苦しいよな 89 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 12:01:11 ] いますでにgetXXX, setXXXの存在を前提として作られているフレームワークが やまほどあるので、基本的にはシンタックスシュガーになるんだろうな。 obj.prop = xxx とか書くにしても、バイトコード上では setProp(xxx)になってるとか。 90 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 12:07:39 ] そりゃそうだろ 91 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 12:21:18 ] >>88 俺はC++も好きなタイプなので、 Javaの言語領域で機能増えるのは嬉しい気持ちもある反面、 やりすぎて失敗しないのを祈りたい気持ち。 既に十分複雑だからね。抱えているプログラマ層を考えると。 92 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 13:03:03 ] Perlがあんだけ使われてるのみると、記号が増える分には問題なさそうだ。 93 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 13:36:50 ] ヒアドキュメントって、国際化対応とかどうするの？ 94 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 17:59:29 ] それでなくても、ヒアドキュメントなんか、めったに使わないからな。 めったに使わないもののためにコンパイラ作りにくくすることもない。 95 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 19:15:47 ] ヒアドキュメントはあかんでしょ なんでヒアドキュメントかっていうと基本的に書く側の都合じゃない そこに書きたいっていう。 視認性は悪くなるし文法なんて無茶苦茶。 あれを使いたくなる理由は、簡易テンプレートエンジンとして使えるからだと思うんだけど テンプレート処理がしたいんだったらIDEとか開発ツールのアシストで 何とかなると思うんですけどね。 ScriptingAPIと同じ扱いでいいんじゃないかと思う。 あれも構造が類推できないスクリプト言語がソースにヒアドキュメント形式で生で埋め込まれてたらと思うとぞっとする・・・ 96 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 19:54:22 ] >>94 ちょっとまて、ヒアドキュメントごときでなんでコンパイラが作りにくくなるのだ？ あんなの、字句解析部をちょこっといじれば済む機能だぞ。 おまえ、コンパイラの作り方もわかってないだろ。 >>95 ヒアドキュメントで済むことをIDEとか開発ツールのアシストを使わなきゃいけないということに疑問をもたないのか。 HTMLページをまるごと埋め込むのならアホだけど、テストデータとその期待値を埋め込むのなら ヒアドキュメントはすごい便利なんだけど。 つーか、「そんな機能必要ない」「IDEのサポートがあれば十分」とかいってるやつらって、実際その機能が追加されたら「これはEoDを実現するすばらしい機能だ」とか言い出すんだろ。 Genericsだって、最初は「C++のテンプレートは複雑だから同じような機能はJavaには必要ない」とか揃っていってたくせに、いざ実装されるとみんなGenericsマンセーなんだよな。 プロパティだって、今までgetterとsetterはEclipseが自動生成してくれるから問題ないとか言ってたくせに、それが実装されると「これは便利だ」とか言い出すんだぜ、絶対。 Javaにない機能は「そんなの必要ない」と言い切り、実装されれば「すばらしい進化だ」と手のひらを返す。ほんと学習しねーよな。 >>93 なんで国際化が必要なん？ふつうにStringリテラルと同じ扱いでいいじゃん。 97 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 20:01:41 ] ヒアドキュメント作るとして、懸念があるとすれば改行記号の扱いぐらいかな？ 98 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 20:02:14 ] >>96 だから当時「いらない」と言ってた人たちは恥ずかしくなって黙ってしまって、 今度は別の人が別の機能に「いらない」といってる、くらいの想像力はないのか？ 実際まったく同じ人だったらキモイだろう。 ヒアドキュメントはあれば便利だと思う。 一方でコンパイルされたバイトコードの中（つまりはclassファイル）の中に そのヒアドキュメントの内容が埋め込まれるんだったらダサすぎなのでペケかな。 99 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 20:04:24 ] >>96 > 最初は「C++のテンプレートは複雑だから同じような機能はJavaには必要ない」とか そんな阿呆な事言ってた奴は居るのか？ 少なくとも俺は聞いたこと無いぞ。 erasure よりマシな実装方法もあったんじゃないの？ って話なら結構聞いたけど。 100 名前：98 mailto:sage [2006/05/27(土) 20:07:46 ] あ、しかしまあ、String document = ""が自動生成されると考えると さほどヘンでもないか。 しかし一方で、ヒアドキュメントってドキュメント中に変数値を簡単に 埋め込めないとあまり使い道がないと思うんだがどうだろうね。 式言語っぽく${変数名}なんてのを採用すると、式言語パースが必要に なるかな。 101 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 20:15:06 ] Stringで生成されるなら%dとか%sでいいだろ 何のためのフォーマッタだ 102 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 20:25:12 ] それだとあとから変数をセットしなくちゃいかんじゃないか。 103 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 20:43:44 ] >>102 そういうことなら、ドキュメントの生成とその中の文章の埋め込みまで やっちゃわないと駄目ね >>96 そのアホが出てくるからコードのメンテナンス性が落ちちゃうんだよなぁ でもそれは、コーディング規約でやらないようにさせるっていうのなら ツール用意して・・・・っていう話と比べてもどっちもどっちだと思うが 他の言語で利用されて便利なヒアドキュメントのいいところだけをＪａｖａらしく取り込んでくれれば いいとは思う。 特殊なコメント記法を入れて、コメントを識別子つけて参照できるようにするってのはどうかな？ /*** <html><body> ほげひげは、${age}歳です */ あ、名前つけんのどうしよう それよりは、特殊な改行付き文字列定義をかけた方がいいか・・・・ String document = ''' <html>ほべー げれげれー </html>'''; うーん、ターミネータがきめうちなだけのヒアドキュメントになったぞ。 104 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 23:11:41 ] >>96 > なんで国際化が必要なん？ふつうにStringリテラルと同じ扱いでいいじゃん。 そりゃそうだよね。 javacのソースの文字コード、 Shift_JISがディフォールトなのそろそろやめてくれないかな… 105 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 23:13:48 ] >>104 なにいってるの？ 106 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 23:40:47 ] javacのソースの文字コードのデフォルトは、プラットフォームのデフォルトと 一致している予感。 107 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 23:41:29 ] >>104 LANG=ja_JP.UTF-8 export LANG 108 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 23:59:04 ] >>107 どこのJDKよ? 109 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 00:09:32 ] 馬鹿が涌いてるな。 110 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 00:13:00 ] >>99 そうだね。Genericsに関しては、初期の頃からJavaプログラマの間でも、 Javaの欠点として言われていたし、Javaを拡張してGenericsを導入して欲しいという 提案も比較的初期の頃からあった。まあ、最近になってJavaにかぶれた人で、 ひょっとしたらそういう人は居るかもしれんが、ごく少数だろう。 111 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 00:47:29 ] オプションつければええやん 仕事でコード書くときは、普通レポジトリ中のロケール合わせて ビルドオプションにもそれ入れておくでしょ？ まぁあの書き方からして>>106をしてるっぽいんだが・・・・ >>110 複雑でいらねっていわれてたのは、ポインタと演算子のオーバオードだという記憶だねぇ それが、今度はとうとう . 演算子をオーバロードすることになるわけか・・・ 112 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 01:26:57 ] Parameterized typeもいらないって言っていたヤツいたけど、総じて馬鹿だった。 113 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 01:46:46 ] 演算子のオーバーロードまではいかないんじゃない？ Java 5がでたときのインタビューかなんかでも、演算子のオーバーロードは Javaを複雑にするので入れたくない、とSunの誰かが答えてたはず（ソース見つからず） プロパティを obj.prop = value で設定できるようになったとしても、それはオーバーロード とは言わんと思うし（シンタックス・シュガーだよね） Dolphinでオーバーロードをサポートするとか言う発表があったんだっけ？ 114 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 03:11:55 ] >>99 Gosling自身が「いらない」と言っていたんだけど。Bill Joyは「parameterized typeがあればどんなにいいだろう」といってたけどな。 つか、ほんとに聞いたことないのか。それはいくらなんでも世界狭すぎだろ。 あれか、恥ずかしい過去はなかったことにしたがってる連中か。 EJBのときとかわんねーな。あれも推進派だった連中が今は「やっぱりEJB2は複雑だったよな、アノテーションマンセー」だもんな。自分たちがどれだけEJBを押し付けてきたのか忘れたらしい。 foreach文もそうだよな。foreach文なんていらね、Iteratorパターン最高といってたヤシばかりだったのにな。 ほんと恥ずかしい過去はなかったことにしたいらしい。 115 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 03:23:36 ] foreachは聞いた事ないけど 116 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 03:48:27 ] いやいくらなんでもEJB2が複雑じゃないなんて話は聞いたことがない。 EJB2じゃないけど、Strutsだって「あれは壮大なネタだろ」とか言ってたくらいで、全般的に 冗長なフレームワークは嫌われてたように思うが。 genericsでは何度か見たが、一方でMapがタイプセーフでないことに苦しめられたって 意見もあったわけで、バランスは取れてただろ。 Java言語をシンプルなままにしておきたいという希望は俺にもある。一方で、書くのが楽に なって欲しいという希望もある。一人の中でもせめぎ合いがあるんだから、スレ内でどっちの 意見が出たって不思議には思わんがね。 117 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 03:56:09 ] >>96 ヒアドキュメントがあると、文脈自由文法じゃなくなってしまうからJavaCCとかのパーサージェネレータで作りにくくなるよ。 118 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 05:33:15 ] >>116 EJB2が複雑という意見はあった。しかし、それは一部の開発者のみ。EJBを推進する連中のほうがずっと多かった（理由は「それが標準だから」だとさ）。 Strutsだって同じだろ。雑誌記事みればわかるじゃん。どれもEJBマンセー、Strutsマンセー。 EJBやStrutsを明確に批判したのはRodやTateなどごく一部。日本じゃ皆無。 >>117 単純なヒアドキュメントは字句解析だけで実現できる。パーサはいじる必要ない。 つうかな、これだけ機能がごちゃごちゃ増えてるのに、ちょっと文法たすだけなのがなんで問題なんだ。 今のJavaはコンパイラ作るのがすごい面倒な言語になったけど、それは機能が増えたせいで構文解析よりあとが大変になったからだろ。 それにくらべたら、構文解析までなんて簡単。ヒアドキュメントの追加ぐらいわけない。 ほかにずっと大きな問題があるのを見ないふりして、「パーサジェネレータで作りにくくなる」なんてささいな問題をとりだすなよ。 119 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 06:11:10 ] >>118 少なくとも、ヒアドキュメントは「ずっと大きな問題」じゃないな。 120 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 06:38:50 ] >>118 つ ttps://mustang.dev.java.net/ 時代は貴方を求めています。言い出しっぺの法則ってことでﾖﾛﾋﾟｸ 121 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 08:04:10 ] 俺はforeachいらねーわ。 122 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 09:46:04 ] >>114 GoslingがGenericsをいらないと言っていたというのは、信じがたいのだが。ソース希望。 Java House MLのアーカイブやその他の場所で引用されていた過去のGoslingの発言を見る限りでは、 Genericsの導入には前向きだったように思える。 あと、世界狭すぎなのは自分の方なのかも、って考えは無いのかね。 123 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 09:53:24 ] >>118 Rubyにあるような、式を埋め込めるヒアドキュメントはパーザをいじる必要があるけどな。 実際のところ、ヒアドキュメントはあれば便利だろうし、使うだろうけど、そこまでこだわる 程の機能か？あと、そんなにヒアドキュメントが本当に欲しければ、こんなところで ぐちぐち言ってるよりも公式に提案した方が良いかと。Genericsやその他の言語拡張だって、 要望が多かったから取り入れられたわけだし、ヒアドキュメントも場合によっては取り入れられる こともあるかもしれん。 124 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 10:07:39 ] Goslingが否定的だったのは、 C++のtemplateの特殊化やC++,CLOSなどのgeneric functionだろ。 operator overloadはかなり初期から批判的。 Bill JoyとGoslingが"暴力沙汰"になりそうになったのは、 Billがgenericsはゆっくり考えることにして、generics抜きでJavaをshippingしようとしたから。 Goslingは、進行はJCP任せだけど、collectionのreliabilityを増すと積極的。 C/C++に対する大きなアドバンテージと考えているから。> reliability www.gotw.ca/publications/c_family_interview.htm 125 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 10:24:43 ] >>124 本題からはずれるのだが、C++のgeneric function(=テンプレート関数のことか？) とCLOSのそれ(=マルチメソッド)は全く意味合いが異なるのでは。前者は静的に 呼び出しが決定され、後者は動的に呼び出しが決定されるので。 126 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 10:44:44 ] 性的か童的か違うと「全く意味合いが異なる」のか? 「関数テンプレート」が正式名称な。C++03で間違っている部分も修正。 127 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 10:51:28 ] >>126 全くというと言いすぎだったかもしれんが、少なくとも意味が異なるのは事実。 Javaのメソッド **オーバーロード** とメソッド **オーバーライド** が異なるのと同じ。 関数テンプレートが正式名称というのは、知らんかった。すまん。 128 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 10:56:49 ] >>124は、わざわざ"generic function"って書いているんだから、 クラスに属さない多相型の関数のことを言っているのは自明だよ。 性的なw特殊化はわざわざ別に書いているし。 129 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 12:10:38 ] >>128 言いたいことがよくわからないのだが、C++には関数テンプレートとは 違う、"generic function"があって、それは、CLOSのように、実行時に オブジェクトの型に応じて、動的にディスパッチしてくれるのか？ 130 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 12:49:01 ] "generic function"をCLOSの意味に制限して、 意味不明って言っても仕方ないじゃないの? 一般名詞としての"generic function"は、C++のWGでも出ているよ。 例えば、www.research.att.com/~bs/evol-issues.html generic programmingで使うparametric polymorphismを持った関数が"generic function"。 知らないのはよっぽどうとい人だと思われ。 131 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 18:45:57 ] >>130 いや、"generic function"をCLOSの意味に制限したいわけ じゃなくて、CLOSのそれとC++のそれは意味が異なる機能なのに、 124が > C++,CLOSなどのgeneric function と、C++とCLOSのgeneric functionが同じ機能かのように言っていたので、 つっこんだだけ。 132 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 22:01:40 ] >>123 ヒアドキュメントはあくまで例のひとつ。 「そんな機能いらね」といってたくせにそれが実装されると意見を180度変えるJava屋さんが多すぎてうざいというのが主張内容。 JCPに提案しろとかポイントはずれてる。 133 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 22:29:35 ] >>131 > C++とCLOSのgeneric functionが同じ機能かのように言っていたので、 FUDかよw 134 名前：133 mailto:sage [2006/05/28(日) 22:52:36 ] お口直しに、 www.osl.iu.edu/publications/prints/2003/comparing_generic_programming03.pdf 結局propertyは>>86の言うように、JSR245なの? 135 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 23:22:33 ] >>133 132だが、いい加減しつこいかもしれんが、どの辺がFUDなんだ？ 136 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 23:25:08 ] >>135 間違えた。「132だが」は、「131だが」ね。 137 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 00:35:52 ] >>132 確かにポイントがずれてたかもしれん。 でも、結局、 > 「そんな機能いらね」といってたくせにそれが実装されると意見を180度変えるJava屋さんが多すぎて というのは、そんなに居るかなあとしか自分は思えない。あなたの 周りはそういう人ばっかりだったのかもしれんが、全体として どうだったかというのは、ソースが無い以上、わからんし。 138 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 08:50:44 ] えーい、IDが無い板でそういう話題はやめーい。 技術の話でぶつかるならともかく！！！！ 139 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 08:59:23 ] まあ、ヒアドキュメントは実装されても意見を180度変えるJava屋は少ないだろうな。 いらね。 140 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 09:10:29 ] XMLで出来るんだから、プレインテキストはいらんだろ。 141 名前：デフォルトの名無しさん [2006/05/29(月) 12:41:52 ] >>134 JSR 245のexpression languageのところだけ、 つまり JSR-000245 JavaServer Pages 2.1 FR から抜き出された JavaServer Pages 2.1 Expression Language Specification だけ入るんじゃないのかな。property関係のところは。 1.6 Operator [] and . The EL follows ECMAScript in unifying the treatment of the . and [] opeartors. expr-a.idenfitifer-b is equivalent to expr-a["identifier-b"]; this is, the indentifier identifier-b is used to construct a literal whose value is the identififer, and then [] operator is used with that value. (以下、式を評価する時のルール;略) java.elのELResolver.getValue()辺りのインターフェースは どうなるのか知らないが。もともとJSPのproperty用だからさ。 142 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 16:53:15 ] >>137 まさに、すぐ下にいるじゃん。>>139,140 今まで幾度となく同じことが繰り返されてきたし、これからもおんなじ。 143 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 16:58:39 ] つまり、>>43 がXMLリテラルがあればヒアドキュメントいらね、って言い出すと予言してるわけね。 144 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 17:34:37 ] ヒアドキュメントはもう話題としてはいいだろ。つまんねえし。 145 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 17:49:01 ] >>142 ヒアドキュメントなど、間違いなく不要。 146 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 23:48:08 ] あってもなくてもどうでもいいや。 自分ならヒアドキュメントで書きたくなるような文字列はコードと分離するけど。 147 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 01:46:32 ] まあつまりさ、genericsにせよヒアドキュメントにせよ、あれば使うし無ければ 今を受け入れるか、Javaを使わないしかないだろ。 おれはヘタレなのでMapに想定していないオブジェクトをつっこんじゃって、 キャストで落ちるなんてことをよくやってたからGenericsはすごくありがたい けど、なけりゃないで、無いんだからどうしようもないから受け入れてただけ。 Genericsがないからまともなコードが書けません、なんて仕事では言えない んだし。 148 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 02:42:09 ] いや、ヒアドキュメントは、あっても使う機会がない。 149 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 05:26:34 ] Ruby並にいろいろできるなら欲しいな、便利だし 150 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 06:57:54 ] スクリプト言語と比較されてもなあ… ま、俺も>>146と同じでどっちでもいいや。どうせ使わないだけだし。 151 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 09:27:59 ] つうか、Ruby並にいろいろやりたいならJRuby使えばいいだけじゃん。 152 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 09:31:37 ] 時々でいいのでGroovyのことも思い出してあげてください。。。 153 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 09:32:36 ] あ、Groovyってヒアドキュメントなかったかも....orz 154 名前：デフォルトの名無しさん [2006/05/30(火) 09:34:55 ] >>147 List<Map<String,Object>>とかだとListとだけかかれるとソース追わないと中身確認できないのはきつい ドキュメントでしっかり書いてくれるところならいいがListとだけかいているとぶち殺したくなる もう1.4時代にはもどれんよな 155 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 09:48:47 ] >>153 Groovyには、式を埋め込める複数行文字列リテラルがあるよ こんな感じ def i = 100 println """ Hello ${i} """ これをヒアドキュメントと言っていいかは正直わからんの だが、機能的には、文字列の終端となる記号を自由に指定 できないことを除いて、ほぼ同等だと思う 156 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 15:45:10 ] ヒアドキュメントは*絶対*に入れて欲しくない こんなもの、保守やデバグを考えるとぞっとする チームで禁止しても絶対使う奴が出てくるから嫌だ 157 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 16:54:31 ] どうせコンパイルして逆コンパイルしたら普通の文字列リテラルになるから問題なし。 158 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 17:55:57 ] ヒアドキュメントいれただけで保守やデバッグができなくなる>>156のレベルに乾杯 159 名前：デフォルトの名無しさん [2006/05/30(火) 18:06:25 ] まぁお行儀の悪いプログラムを推奨してるかんじだしあまりいいものではないな 160 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 20:21:24 ] コンパイラ機能とあわせて使うと意外と便利かもよ てかコンパイラ機能ってクラスキャッシュ直ぐ満杯になる欠点とかないの？ 161 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 23:03:08 ] >>160 そんなことされると、さらにgkbr 162 名前：デフォルトの名無しさん mailto:sage [2006/06/02(金) 02:54:34 ] ヒアドキュメント入れるときの妥協点として コンパイルオプションでヒアドキュ封じができるようになればちょうどいい感じで導入できないかね？ プロジェクトで使う人もこまんないんじゃない？ 163 名前：デフォルトの名無しさん mailto:sage [2006/06/02(金) 07:44:25 ] そういう問題じゃない。 というかそこまでして導入するもんでもない。 164 名前：デフォルトの名無しさん mailto:sage [2006/06/02(金) 17:03:39 ] プロパティは、 言語として加わるのか、 XML対応としてXMLの属性にgetValue/setValueするAPIがJDKに加わるのかどっち? 関連JSRは、 JSR 227: A Standard Data Binding & Data Access Facility for J2EE(TM) JSR 245: JavaServer(TM) Pages 2.1 JSR 252: JavaServer Faces 1.2 JSR 295: Beans Binding あたり? Expression Language周辺 165 名前：デフォルトの名無しさん mailto:sage [2006/06/03(土) 22:35:13 ] >>40 なんだからPerlの q!文字列!やPHPの'文字列\n$変数'と'文字列$変数'との 違いを表してるブツみたいだな。 PHP的なものならまだしもPerlのq!文字列!みたいな 混乱するブツになるのは避けてもらいたいところだよな。 ダブルクォーテーションが無いだなんて、 あれ使う前に何か宣言でもするのかな 166 名前：デフォルトの名無しさん mailto:sage [2006/06/03(土) 22:37:29 ] >>46-47 そのまんま@Propertyアノテーションとして使えばいいやんか 167 名前：デフォルトの名無しさん mailto:sage [2006/06/03(土) 22:39:21 ] >>48 C#みたいな表向きは set/getと書くだけでプロパティが使えるが 実際には内部ではプロパティ変数名がたとえばtest のとき実際にはGet_test(), Set_test() というメソッドが定義されているとコンパイラに解釈されるという奴でどうにかなるんだろう。 ただし、このときGet_test(), Set_test()という名前のメソッドを定義するとC#ではエラーになるが。 168 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 01:52:45 ] >>167 そういう暗黙の定義が適用されるのは、 対XMLデータとか、シリアライゼーションとか、 定義をクラスライブラリ側が持っているケースでしょ? それは既にBeansやServer PagesのELであるよね。 JavaDocのtagもpropertyが増えてる。 Dolphinのは、言語がproperty採用するって事なんじゃないのかな? 要するに、setter/getterはプログラマが記述して、 フィールド参照がsetter/getterに置き換わるヤツ。 169 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 01:56:45 ] >>96 遅レスながら激しく同意。ほんとJavaには呆れる。 170 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 02:11:29 ] >>165 > >>40 > PHP的なものならまだしもPerlのq!文字列!みたいな > 混乱するブツになるのは避けてもらいたいところだよな。 例えばの話だが "<p id=\"hoge\" onmouseover=\"hige('fuga')\" class=\"hage\">"; q{<p id="hoge" onmouseover="hige('fuga')" class="hage">}; どっちが見易いかっつう話だ。 q{}とは違うが正規表現の場合も考えてみ。JavaよりC#の@の方がまだマシだろうに。 171 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:21:22 ] >>75 そんな書き方するのがいやだったら インクリメントできるメソッドを定義したほうがいいんじゃないのか？ 172 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:24:18 ] >>96 いっておくがC++のtemplateとJavaのgenericsとはまったく別もんだよ。 比較サイトでも似て非なるものであると書いてある。 よって全然手のひらを返したことにはならんよ 173 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:25:14 ] >>96 ヒアドキュメントは下手な奴が使うとソースコードを読みにくくするからな。 Perl厨が書いたコードみたいにな。 174 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:27:07 ] >>172 C++ templateの重要な特性である、コンパイル時プログラミング ができるという機能をJava genericsは持って無いし、別物と言って 良いだろうね。 175 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:27:51 ] >>114 だからC++のテンプレートはJavaのGenericsと全く 同じではないと何度言ったら(ry だからあれほど言ったものを

---

---

[ 続きを読む ] / [ 携帯版 ]

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