言語は育てるもの：Javaの未来の姿とは 189
ストーリー by Oliver
かゆいところをなくせ 部門より
かゆいところをなくせ 部門より
calappa曰く、"SunのJavaのサイトに Guy Steele 氏へのインタビュー記事が掲載されている。たぶんすごい有名人なのだろうが、Javaの言語仕様を設計するような偉い人であり、J2SE1.5 で導入予定というあの generic type を推進した張本人らしい。当記事によると、プログラミング言語は使われることで成長するものなので、開発者が育てやすい拡張性を提供しましょうということで、さらには演算子のオーバーロードまでやりたそうな雰囲気。これまでも言語仕様や API が成長するたびにもう勘弁して状態だったのに、これ以上成長したらもう Java じゃなくなると思うのですが、Java プログラマの皆さんはどうでしょうか。"
GLS (スコア:4, 参考になる)
プログラミング言語界ではイニシャルだけでも 通る有名人ですが、 外では「たぶんすごい有名人なのだろうが」くらいの知名度なのかな。
等々。
逸話その一 (スコア:2, 興味深い)
大学の廊下で人とすれ違うとよく
「あの胸ポケットに何本もペンを差してるのは誰?」
とささやかれた。もちろん、胸ポケットの補強材(ペンのクリップ部
との摩擦で擦り切れないよう縫いつける)の愛好者だった。
#なにかの雑誌に掲載されたテープ起こしの日本語訳をやったのは
#私でした。頼んだ業者がコンピューター用語をまったく知らない
#せいか、聞き取りも訳も目茶苦茶だったのでお鉢が回ってきたとか。
#Cellular Phoneが「細胞状電話」だもんなー
逸話その二 (スコア:2, 興味深い)
長髪にヒゲ、ラフな服装が流行していた。体制的な物事を嫌い、
世間とは違った事をし、反動的である事が何よりも重要だった。
ある日そうしたヒッピーの学生が集うダンスパーティーに、
彼は大変フォーマルな服装で参加した。すると、長髪ヒゲの友人に
「おい、なんて体制的な格好をしているんだ。もっと反動的で
いたらどうなんだ。」
落ち着いてGuy曰く
「うん、だから僕はみんなと違った服装をしているんだ。」
#細部は違っていたかと思いますが、大筋こんな話。
Re:GLS (スコア:2, 興味深い)
昔、言語の外堀あたりで仕事していましたが、Lisp/Scheme系な人には
Guy L. Steele Jr.の信奉者と思える人いましたね。
今現在、熱いコメントが少ないのは、みなさんお休みだからでしょうか。
C言語では、K&Rは必須でしたが、C: A Reference Manual(C:ARM)が
「仕事」で参考になったのをよく覚えています。4th Editionくらい
だったでしょうか。
日本語訳の本もあったようですが、そちらは見たことありません。
たぶん、原書で読む方が間違いないでしょう。
自分も、軽いGuy L. Steele Jr.の信奉者かもしれません。
もしかしたら、美学やエロスの世界かも。
Re:GLS (スコア:1)
東大の 萩谷先生 [u-tokyo.ac.jp]の こんなエッセイ [u-tokyo.ac.jp] もありました。
Re:GLS (スコア:1)
読みました。「優雅」とか「Lispの思い出」なども。
「楽しい方ですね」と書いたら失礼でしょうか。
学生時代に初歩のプログラミングの講義をとっていたのですが、
Lispには感銘を受けました。「こういうものがあるのか」と。
一応、数学系出身だから惹かれるものがあるのかもしれません。
つまり、二分木、再帰あたり。それとGC。
Re:GLS (スコア:1)
ラムダ計算の提唱者であるchurchとか「チャーチ・ロッサ性」の Rosserクラスだと、LISP系であろうが無かろうが、 計算機科学界 の者は知って手当然だけどさ。
「たぶんすごい有名人なのだろうが」じゃなくて、 「あ、schemeを作った人ね」とか 「誰？それ」くらいの知名度だと・・・。
CやFORTRAN90の言語仕様にも関わったらしいけど、 多少詳しい人でも認識は、「C？カーニハンとリッチーが作ったんでしょ」 「FORTRANはバッカスが作った」がいいところだし。
P.S. ゴスリングはjavaで有名になって、emacs(gosmacs)の作者というのは 知らないとの方が多くなってしまった。
Re:GLS (スコア:1)
ああ、確かにLisp系の人ではありますね。1980年代から言語やってる人なら、その人の専門言語が何であれ、Lisp界とつながりがあることが多いと思いますが。トップ5に入るかと言えば他にも重要な人はたくさんいますからねえ。
リンク先はSchemeの論文アーカイブですからLisp/Scheme系の論文しか置いてないんですが、並列計算関係や関数型言語関係の論文も出してます。
ただ、オブジェクト指向言語を考えるなら、アクターとクロージャの等価性を示している"LAMBDA: The Ultimate Declarative" くらいは(その見方に賛成するか反対するかはともかく)基礎教養と言えるのではないかと。
Re: gls (スコア:1)
>近頃の若い者は知らんことを恥と思っとらん、つーか。
知らないことは仕方ないとして、タレコみを採用し記事にする過程でそのあたりを編集者がフォローしてもいいと思うのですけどね。
Structure and Interpretation of Computer Programs の著者でもありますね。
Re: gls (スコア:1)
> 著者でもありますね。
違うのでは？
title: プログラムの構造と実行
(Structured and Interpretation of Computer Programs)
author: Harold Abelson and Gerald Jay Sussman
with Julie Sussman
これだけだと揚げ足とりなので。
この本は、MITにおける1年生用の入門コース(6.231というクラス名らしい)で
使われている教科書です。
入門コースの本なのですが、自分はまったく理解できなかった本です。
MITって頭いいんだなーとつくづく思った。自分の頭の悪さを棚にあげて。
なおSchemeの作者 Guy Steelは、正式にはGuy Lewis Steele, Jr.
というそうです(細かい？)。
Re: gls (スコア:1)
ご指摘のとおりです、頭の中で Steel と Sussman がごっちゃに なっていました。訂正ありがとうございまず。m(_._)m
# かっこわる。
Re: gls (スコア:1)
それでは
あなたはゼロの概念を考え出した人の名前を知っていますか？
まあ、揚げ足取りは置いとくとして
プログラム言語を使う側から言わせてもらうと
Java は言語仕様上の美しさ(?)を追求しすぎていて
たとえば C/C++ のマクロやテンプレートのような
泥臭いけど便利な機能が少ないお堅い言語というイメージがあります。
これからは、java も C++ のような混沌とした言語仕様になるんですかねぇ。
是非ともC→C++のような育て方は間違っていなかった、と証明していただきたいものです。:-)
Re: gls (スコア:1, すばらしい洞察)
でもって、知らないことを認めないことは恥だとも。
歳くうと共に、知らないことを認めずに誤魔化せる技術を身に付けて
より怠惰になっていく自分が悲しい。
# 無駄に歳くっている気がするのでAC
Re: gls (スコア:1)
言い方は悪いけど同意できます. 普通に考えればprimitiveとclassが同居している時点で, 現実的な, あるいは見方によっては汚い設計だと見るべきでしょう.
Re: gls (スコア:1)
Java++ (スコア:2, おもしろおかしい)
（一部で）C++が忌み嫌われたように、Java++も同じ運命を辿る。
もっとも、後置演算子なので『まだ足されてない』んだけど。
Re:Java++ (スコア:1)
・Javaは、C++よりはましだと思う。
でも他のどの言語よりもよいかというと、そうは思わない。
悪くはないけど、そんなによくもない。
・今のJavaは、言語仕様の肥大化よりも、関連技術の肥大化のほうが問題ではないか。
JDBC、Servlet、JSPぐらいまではよかったが、EJB、カスタムタグ、JSTL、…など
捕らえきれない。
C++は言語仕様自体が膨らみすぎたけど、Javaは関連技術が膨らみすぎて困る。
＃おまえの頭が悪いといわれればそれまでだが。
・ほんとうに開発者のことを思ってくれるのであれば、クラス名やメソッド名を
もちっと短くしてほしい。書くのも面倒だが読むのも面倒。
C++はクラス定義が面倒だったな。
Re:Java++ (スコア:1)
> 対応してても、標準化されてなくてAPIが乱立してるか、あるいは、
> 単に存在を知らないだけでは。
はは、この指摘はその通りかも。
ところで聞くんだけど、例えばEJBって筋がいいと思う？
EJBはオブジェクトとRDBMSをむりやりくっつけたようにしか
思えないんだけど。
オブジェクト指向DBのほうがずっと素直で使いやすかったな。
> 長いからいいんじゃない。読んだだけで何かわかる。
> その良さがわからない君は使えないプログラマだと断言できる。
これはちょっと反論するかな。
例えばtoString()がstr()になったら、そんなに難しい？
getElementAt()がat()になったら、理解できなくなる？
Javaでも、EnumerationのhasMoreElement()やnextElement()が
IteratorではhasNext()やnext()のように短くなったじゃない。
このくらいの長さだったら特に不満はない。
そんなにおかしな要望だとは思わないけどね。
みんな、うざったくないのかなー。
もしかしたら、変数名もやたら長い名前を使いたがるタイプの方ですか。
ResultSetMetaData resultSetMetaData = resultSet.getMetaData();
とか。
ぜひあなたの意見をきかせてね。
Re:Java++ (スコア:1)
> もしかしたら、変数名もやたら長い名前を使いたがるタイプの方ですか。
> ResultSetMetaData resultSetMetaData = resultSet.getMetaData();
> とか
変数のスコープを考慮・指摘せずに自説を展開している時点で駄目だと思われます.
Re:Java++ (スコア:1)
よく勘違いされるみたいだけど，EJBの眼目は，Entity Beansの永続化にあるんじゃないよ．EJBは，分散オブジェクトのバスという位置づけではじめられたものだから．
つまり，眼目は分散オブジェクトのほうで，Entity Beansの永続化っていうのは，あくまで付加的な機能として考えられたってこと．だから，Entity Beansの永続化の部分についての議論を「EJB」についての議論にしないでほしい．
Re:Java++ (スコア:1)
> EJBは，分散オブジェクトのバスという位置づけではじめられたものだから．
そうなんだ。知らなかった。ありがとう。
でも分散オブジェクトの「バス」っていうのは何？
プロトコルというぐらいの意味あいでしょうか。いや知らないもので。
簡単でいいので、教えていただけるとありがたい。
> つまり，眼目は分散オブジェクトのほうで，Entity Beansの永続化っていうのは，
> あくまで付加的な機能として考えられたってこと．だから，Entity Beansの永続化の
> 部分についての議論を「EJB」についての議論にしないでほしい．
なるほどね。
あれ、でも分散オブジェクトで必要なのは永続化ではなく直列化のほうでは？
永続化は、直接には関係しないと思うけど。
永続化の機能と、分散オブジェクトでのみ必要な機能とを、分けることは難しいのかな。
Re:Java++ (スコア:1, おもしろおかしい)
> はっきり言って、眠い頭でも理解できるコードならなんでも良いですよ。
寝ぼけてるヤツはコードを触るな。
> 1.人間に記憶力を求めないで、お願い。
そのために便利なエディタがあるんです。
定義位置を参照できたり、マウスを持っていくだけで…ほら整数型だ。
> 2.自分の感覚を他人に求めないでおくれ、頼むから。(略語とか)
文化に馴染むタイミングだと思う。
strcmpに何の抵抗も無いでしょ？
# あなたがＣユーザであることを願う
> 3.絶対良いと言う確証もなしに非標準な技を使わないでよ、ほんと。
文章どおりなら納得。でも、確証無しに技を使う？
> 4.後からコードを読む人を思いやって下さいね。
i++; // 変数ｉに１を加える。引くんじゃないの。前置・後置は気にしないこと。
# 注：ネタです
Re:Java++ (スコア:1)
> 読みにくくなるのは勘弁願いたいトコ。
このさじ加減に、つまりわかりやすい・わかりづらいと感じる
しきい値に個人差があるんだろうね。
Javaは、必要以上に名前が冗長すぎて、わかりやすいのかもしれない
けれど逆に読みにくいと感じていました。
getElementAt()やhasMoreElement()は確かに分かりやすいけど
書くのも面倒なら、読むのもなんか読みにくい。
例えるなら、x * y と書けてほしいのに x.multiply(y) としなきゃ
いけないような感じ。わかるけど、読みにくい。
strcmp()は・・・うーん、strcmp()でいいかなー。
頻繁に使うものだし。
どちらかというと、引数のうちどっちがsrcでどっちがdestだったかを
いつも忘れてしまうので、自分には名前よりそっちのほうが問題だった。
Re:Java++ (スコア:1)
C++に限らず, 万能性を求めた言語ってことごとく失敗, とまではいかずとも先細りになりますよね. PL/Iしかり, Adaしかり.
Re:Java++ (スコア:1)
>STLが使えれば、コードの分量もバグの量も1/10くらいになるのにね。
STLは便利すぎるよね。
ただ、標準ライブラリでしかないので、個人的な意見としては
テンプレートプログラミングの強力さが魅力。
#C++が泥臭いのはC言語自体が泥臭いものだからしょうがない
kusanagi shin
Re:Java++ (スコア:1)
私は、どちらかというと、Java と C++ がこうして引き合わされて天秤に掛けられなければならないことのほうが理解不能だったりします。
どう考えたって、お互い比較になるようなシロモノじゃあなかろうに。。。
むらちより/あい/をこめて。
Re:Java++ (スコア:1)
演算子のオーバーロードには否定的では？ (スコア:2, 参考になる)
まともにJavaでアプリを作ったことのない自分が言うのもなんですが、
「コンパイル時に厳密なチェックを行いやすい」「eclipseのようなIDEが扱いやすい」
「2:8の法則」(要するにバカでもそれなりに書ける)
というのがJavaらしさだと思っているので、genericが入っても変わらないと思います。
というより、genericが入ってより厳密なチェックが出来るのでいいんじゃないかと。
＞当記事によると、プログラミング言語は使われることで成長するものなので、
＞開発者が育てやすい拡張性を提供しましょうということで、
＞さらには演算子のオーバーロードまでやりたそうな雰囲気。
そうでしょうか。自分が記事を見た限りでは、
C++の演算子オーバーロードを"badly abused"と述べたり、
BigDecimalに四則演算を導入するのをわざわざ斜体で"except"と述べたり、
演算子オーバーロードには否定的な雰囲気を感じましたが。
＞これまでも言語仕様や API が成長するたびにもう勘弁して状態だったのに
APIはともかく、Javaの言語仕様ってそんなに複雑ですか？
オブジェクト指向の難しさはしょうがないとしても、それでもCよりも単純な気がしますけど。
Javaは良いとして、 (スコア:2, 参考になる)
(´д｀;)
Re:Javaは良いとして、 (スコア:2, 参考になる)
http://grunge.cs.tu-berlin.de/%7Etolk/vmlanguages.html
うおお (スコア:1)
上の人に「参考になる(+1000000000)」ぐらい付けてあげて下さい。
# 上の人などいない。
(´д｀;)
Re:Javaは良いとして、 (スコア:1, 参考になる)
System.out.println("Hello World");を
Systemとoutとprintlnと"Hello World"という
class,method,……などのトークンに切り分ける
プログラム（のソース）を作るプログラム。
#雑談の前にgoogleしてくれ、頼む。
#http://www.asahi-net.or.jp/~DP8T-ASM/java/tips/JavaCCHelloWorld.html
きみがゆく (スコア:1, おもしろおかしい)
(意)
Javaなんてとっととくたばっちまえ！
#決して、恋歌のつもりで詠んでるわけではないのでAC
#出典は万葉集からです。念のため
Re:きみがゆく (スコア:1, おもしろおかしい)
(意)
いくら拡張して行っても、互換性は保とうね
たとえ進化し続けようとも (スコア:1, 参考になる)
# この9年間でobsoluteなクラス/メソッドがいくつあるか数えきれず。
# タレコみ子とは別な意味でJavaじゃなくなってきていると思うのでAC
Re:たとえ進化し続けようとも (スコア:1)
元コメントの
s/obsolute/obsolete/
然り。
閑話休題
確かに非推奨になったクラス(メソッド)よりも新しく追加された
ものの方が良いという場合が多いので、異論はないのですが、
これだけ増えてくると、どっかでエイヤッと別物にしてしまう、
というのもアリかと思います。(「それはC#」というのはナシね)
とりあえず (スコア:1)
それさえ守っていれば、進化してもいいんじゃないでしょうか？
便利なAPI等サポートしないと、Java開発者が増えないとも感じます。
使ってくれる人がいなくなれば、その言語は枯れていきますし、
その対策として、アップグレードが必要とも思います。
マジ勘弁 (スコア:1, 参考になる)
やーめーてーくーれー。（血涙）
これだから言語設計オタクは(ry
＃かつてC++の演算子オーバーロードでハマリ地獄を見た男より。
あんときはもう・・・納期に遅れてクライアント怒りまくり、
クビ寸前まで逝ったからなあ・・・。オレのせいじゃなかったのが
救いだったのかどうか(w
Re:マジ勘弁 (スコア:1)
むやみに拡張するモンでもない、って言ってんのよ。
>＃集団でコードを書く際には最低レベルの人間に合わせるべし、って
のが鉄則だからねぇ。
１．その最低レベルの人が、コードを書くのに適さないレベルという
ことは無いでしょうか？（ここでは、現実問題としてそんな人も
使わざるを得ないということは横に置いておきます）
２．「機能の使い方が」悪いというのは、どのような使い方をしてい
のでしょうか？差しさわりの無い範囲で状況をお答え頂けると
ありがたいのですが。
Re:マジ勘弁 (スコア:1)
>私はその「現実問題」を言ってるのであって、理想論を展開してる
>わけではないんですが。
いえ、それだからこそ理想とのギャップを知りたいわけです。
現実問題を仰っているのはわかるので、括弧書きしました。
>＃同じ中国人か？って目を疑いたくなるほどレベルの差が激しいんで、
>＃彼ら。国費留学生レベルだと私らよりとんでもなくデキるのもいるんですがねぇ。
そうですか。私が仕事でいっしょになった中国人はデキる方ばかりです。
日本に来られているからでしょうか。１人には「こんな会社長居したら
だめだよ」と言ったら、「そのうち会社を作る予定」とのことで、
数ヵ月後に辞めました。その後自分も「こんな会社」を辞めましたが（笑
>特に演算子オーバーロードに関して言えば、どういう挙動をするか読みにくい
>部分があるですよ。
>自分で定義した分ならともかく、他人に勝手にこそっと定義されるとね・・・。
個人的にある程度、同感です。
>＃私のケースでは、私の定義したクラスに対して目立たないところ（とーぜん
>＃全然関係ない階層ね。）にちょこっと勝手に複数の演算子オーバーロードを定義
>＃してくれたﾔｼがいて。そのおかげで私のクラスが思いもしない挙動をしてくれて
>＃どーしてなのかわからなかった時がありますた。
全然予想外のところから「お前のモジュールで落ちてた」とか障害報告
が来て、調べてみたら「なんだよこれ」ってやつですね。デキル人が
基本的なクラスなりテンプレートを書いたりするわけですが、しわ寄せ
が来ることも。
興味としては解決話を聞きたいところではありますが、それを書かれ
るとばれそうな気もします。やぱり、ヘッダとそのコードを見たくなって
きました。ここら辺で抑えておくのが懸命でしょうか。
>＃ま、私もヘタレプログラマなんで間違ったこと言ってるかもしれんが。
ACさんがヘタレかどうかはわからないのですが、自分がヘタレなこと
は知っているので、知り合いのデキル人（人事評価でB,A,Sというラ
ンク付けならSランク)に自分のコードを見てもらうようにしていました。
またその人からコードを見せてもらうようにもしていました。
あとはカン所を教わったり。
Re:マジ勘弁 (スコア:1)
>あぁ、なんという怠惰なプログラマなんでしょう。あなたは。(笑)
# 「怠惰」はプログラマの美徳(^^;という意味かなと思いつつ
でも、サラリーマンプログラマの中には
個人の技術力なんてどーでもよくて、
(時間内に会社にいればいいんだろ的な)怠惰な人がいたりする。
そんな人には、ぜひ優れた開発環境でのコーディングをして
バグを減らしてほしいと思う。
最近、仕事で人のバグを直すことが多いので……
そんなことより (スコア:1)
# 今、はまっているプログラマーより
Re:native (スコア:2, 参考になる)
Eclipse すら動いてるし、今や MinGW 版もあるし。
Re:native (スコア:1, すばらしい洞察)
といっても、Hello World するだけでも
100 を超えるクラスが必要になりますし、
GC 等の機能も完備しなければならないので、
わざわざ何MBもする DLL を配布するか、
わざわざ何MBもする EXE を配布する必要が生じると思われます。
> 一般ユーザのみなさま方にとってはコマンドラインの入力なんかできませんし、
> *.jarをダブルクリックすれば実行できることを知ってる人は限られますから。
こちらの理由だけでしたら、
JNI 等を使って起動させるだけの exe ファイルを
添付すれば解決すると思いますが。
Re:native (スコア:1)
(´д｀;)
Re:generic type (スコア:1, 参考になる)
C++のテンプレートってのは「型紙」で、パラメータを与えることでコンパイル時にコードを展開(インスタンス化)する。別の型をパラメータに与えて使う場合はその型用のコードがインスタンス化される。基本的には文字列操作(マクロ展開)のようなイメージ。
Javaのgeneric typeは、パラメータ型ごとにインスタンス化されるわけではない。生成されるコードは１つだけ。 生成されるバイトコードで実行時に型チェックをするコードが含められたりするわけではないので、generic typeを使って書かれたソースコードからコンパイルされたバイトコードは従来のJVMでも実行することができる。 コンパイル時の型チェックができるようになるというだけ。この種の型チェックは、もしgeneric typeがなかったら、実行時にコレクションから要素を取り出すときのキャスト演算でしていたことなので、そのチェックがコンパイル時に前倒しにできるようになった、というただそれだけの話。
はっきりいって、C++のテンプレートとくらべると、Javaのgeneric typeは「ど単純」で複雑さの度合い、理解しなければならないことの量、そして機能差からいって別物と理解するべきでしょう。
Re:generic type (スコア:3, 参考になる)
このようなあつかう型の違いをパラメータとして切り出せるようにしたのがtemplate。コード共有の話です。
Javaでは、この意味でのコード共有は、generic typeがお出ましするまでも無く当初から可能でしたしJDKのAPIの一部に入ってました(java.util.Vector,HashTable、コレクションAPIのこと)。
JavaでC++のtemplateのようなものなしになぜこれが可能だったのかというと、Javaの多くのクラスがObjectを根として持つ大きな階層構造をなしているため、Objectを扱えるStackを１つ定義してあれば、Objectのサブクラスの要素すべてを扱えるからです。（C++はクラス階層に統一的な「根」となるクラスが無いし、あとポインタで扱えない・扱いたくない「値オブジェクト」の問題があったからこうはできなかった。このことにはC++にはGCがない、という根が深い問題とも絡んでいます）
しかしJavaのこの方法でも問題があって、いったんObjectを経由するがために、型チェックが動的にしか行えないわけです。配列でたとえると、Stringの配列を使うときには、String[]を使えばいいのにObject[]を使わなければならない、ということです。Object[]だから要素にMyClassの要素を入れることもできちゃうし、それがわかるのは取り出し時のキャスト時です。これは不便な話ですが、generic typeが無い今までは実際にこんなへんなことを強要されていた。これを、コレクションAPI使用時に、配列と同じように、代入時に、しかもコンパイル時にチェックできるようにしようというのがgeneric typeです。
直接比較できないですね。比較するんだったら、templateと「JavaのコレクションAPI＋generic type」という構図になるかな？ でも、言語が違うからやっぱり直接比較にならない。ただ、templateはC++に合うように、generic typeはJavaに合うようにそれぞれ良く考えられてはいる、とは言えると思われます。コレクションクラスはもとはSmalltalk由来で、 Smalltalkとかだったら、こんなもんは実行時でOKな話ですが、Javaという静的に型づけする言語にコレクションを持ち込んでしまうと、不自然になるのでそれなりに合わせたとゆうわけです。
Re:generic type (スコア:1, 参考になる)
List list = new ArrayList();
String text = (String) list.get(i);
がgeneric typeの導入によって
List＜String＞ list = new ArrayList＜String＞();
String text = list.get(i);
になる。この場合のメリットは
あと＜＞(本当は半角)の中も合わせて型チェックされることになるのでキャストは厳しくなる。
List list1 = new ArrayList();
List＜String＞ list2 = (List＜String＞) list1;
はだめ、
List＜Object＞ list1 = new ArrayList＜Object＞();
List＜String＞ list2 = (List＜String＞) list1;
はOK。
死活問題 (スコア:1, すばらしい洞察)
そこで、レベルが低かったり、自分と異なる価値観や認知世界を
持っていたりするプログラマの存在は、下手すると自分に対して
徹夜や休日出勤をもたらしかねないわけで、マジ消えて欲しいと
思ってるからなのかも知れません・・。
#自分が人にそう思われたことが無いとは言い切れないのでAC
C#のboxing/uniboxingに対応する (スコア:2, 参考になる)
- enumerations [jcp.org]
- enhanced for loop [jcp.org]
- static import [jcp.org]
が同様に検討されていて、enumerationsはC,C++のenumだし、static importはMath.max(a,b)を単にmax(a,b)と書けるようにするもの。loopの拡張はPerl/C Shellのforeachというかあるいはawkのforみたいなもんで、Collection cに対してfor (String s : c) {
}
って書けて、これは
for (Iterator＜String＞ i = c.iterator(); i.hasNext(); ) {
String s = i.next();
}
と等価。配列a[]に対しても
int sum = 0;
for (int e : a)
sum += e;
こんな風にまわせます。
ほかにも「JSR-133 Javaメモリーモデルとスレッド仕様の改定」 「JSR-181 Javaのためのメタデータ機能」というのが控えてます。後者がC#のメタデータと同じかどうかは未確認。