アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
これって。。 (スコア:1, すばらしい洞察)
誰もそんなことを言わないのは（言ってる人がいたら基地外だ）、Linuxという代替物があるから、という側面もあるからですよね。
そうであるなら、今あるオープンな処理系、もしくは、まったく新しいオープンな処理系を、Javaに対抗できるレベルにまで高める（普及させる）ことをこそ目指すべきだと思います。
そもそも、オープンにしないことを指弾するなんて、傲慢も
Re:これって。。 (スコア:0)
これ書いた人はJavaの価値もCOBOLの価値もわかってない人だと思うんだけど。
Re:これって。。 (スコア:0)
価値ではなくて、言語として進化の袋小路にあるって話なんだけど。
別にJavaの価値を否定しているわけではないでしょう。
Javaの言語としての限界は、Strutsが
Re:これって。。 (スコア:1)
回避するための書き方のパターンってのが結構あるもんねえ。
クラスメソッドの多態が出来ればBuilderなんてわざわざ作らなくていいのに、とかさ。
更に悪い冗談なのはJ2EE Patternかな。
もろ、J2EEのデザインのショボさを誤魔化すためのパターンの塊でしょ。
EJBの重さを回避するパターンだって？最初からEJBを軽く作れよな。
StrutsはXMLでプログラム(webアプリでは、それ即ち画面)の遷移を記述する、つまりXMLでプログラミングする
という冗談をやってるわけですが、
あんなの、昨今話題の「継続ベースのwebアプリ」つまり継続が使える言語ならば
普通のコ
Re:これって。。 (スコア:0)
静的型付け言語でクラスメソッドの多態(?)ができるのってありましたっけ？
また、クラスメソッドの多態が出来ても Builder が必要なくなるとは思えません…
> EJBの重さを回避するパターンだって？最初からEJBを軽く作れよな。
自分で作れば？
Re:これって。。 (スコア:1)
Delphi。
コンストラクタ(特殊なクラスメソッドだという位置付けのようです)にもvirtualキーワードがつきます。
ってゆーかつく方が普通です。標準のライブラリで使いまくりです。
> クラスメソッドの多態が出来ても Builder が必要なくなるとは思えません
減りはするとは思いますよ。
>自分で作れば？
あはは。まあそれはそうだ。
ただ、それを言ってもいいなら、言語についても
特定の奴(たとえばJava)以外の選択肢だって
「自分で作れ」で話は済むわけで、
あらゆる批判の意味がキャンセルされ
Re:これって。。 (スコア:0)
Delphi 風の記法をするためには、クラスメソッドが多態できるだけではだめですよね。
> あらゆる批判の意味がキャンセルされるだけ。
まぁそうですね。
批判が建設的でなかったので嗜めたつもりなんですが。
Re:これって。。 (スコア:1)
ん？「Delphi 風の記法」とは、Delphiに数多ある特徴()のうちの、どこまでを指すんですか？
てか、とりあえずここではクラスメソッドの多態の話(だけ)をしてたと思うんですが…
>使ってる言語ごとに頭を切り替えられるようにした方が良いと思いますよ。
それって「妥協しろよ」と言っているに等しいわけで、
かなりショボい意見だと思うんですが。
どの言語の表現力も同じくらいであるならば、
プログラマの頭のほうを切り替えれば話が済むんですが、
実際にはそうではなく、言語には表現力の多寡(や方向性)の相違が
Re:これって。。 (スコア:0)
言葉が足りなくてすみません。
クラスメソッドの多態は、ClassName.MethodName(ArgumentList) って
記法でサポートできるんですか？ という話です。
> 妥協することですか？(藁
あなたが出来ることに関して言えば、そうです。
他の人であれば他の方法もあると思いますが。
> ＃糞環境しか与え
Re:これって。。 (スコア:1)
>記法でサポートできるんですか？ という話です。
Delphiでは出来ます。
ここで、ClassNameの部分がファーストクラスオブジェクト、つまり
(乱暴に言えば)変数に代入できる、値であるってところが味噌です。
(注：ファーストクラスオブジェクトという言葉自体は、オブジェクト指向(のオブジェクト)とは無関係です。なんか不安なので一応説明。)
つまり、ClassNameっていう部分を変数にしておいて、
そこにClassNameとは「同じではない」クラスを代入おくことが(も)出来る、ってことです。
C++だとクラスが変数になることは有りませんし、
Javaだと変数になるものの今度は事実上の弱い型付けになっちゃいます。
(つまりjavaでは、あえてそれっぽいものといえばjava.lang.Classという1つのクラスしか無いし、それのextendも不可能なので。
まあjava.lang.Classだけでも、動的にrefrection系のAPIを駆使して結果的に同じ事をやることは出来ますが、
そこに至るまでに必要なコーディングはかなり長く煩雑です。ご希望の通りのすんなりした書き方とは程遠いです。)
そして勿論、強い型付け言語ですから、ClassNameという変数自体にも然るべき型が有ります。
以下、Delphiの実装を説明しますと、
A ＜-- B
という継承関係(矢印の向きはUML流です。つまり矢の先のほうが親クラス)のクラスが有ったとして、
これに対応する、ClassOfA、ClassOfBというクラス型を宣言できます。
(残念ながら、Aを作ると同時に自動的にClassOfAを作ってくれたりはしませんが、
実際のクラスの関係を逸脱したクラス型を作ることは不可能なので、
必要に応じてクラス型を作れば(間違って作る心配は無いという意味で)大丈夫です)
そして、それを宣言すると、
ClassOfA型の変数にA(自分)を代入→OK
ClassOfB型の変数にA(親)を代入→コンパイルエラー
ClassOfA型の変数にB(子)を代入→OK
という事が生じます。
これは、ClassOfAとかClassOfBとかいう型もまた強い型付けだからこそ
できる(=コンパイルエラーになる)ことです。
そして、前述のように、このクラス型変数に対して直接(素直な構文で)メソッドを呼べますし、
そのさい実際にどのクラスの処理が呼ばれるか？は、
(virtualをつけていれば)クラス型"変数の"型じゃなく、そこに代入されたクラス型"値の"型に、依存します。
Re:これって。。 (スコア:0)
簡単に言うとクラスメソッドの多態を導入するには、
> ClassNameの部分がファーストクラスオブジェクト
である事が必要であるのに Java はそーなってませんよね。
Re:これって。。 (スコア:1)
○ファーストクラスオブジェクトな「クラス」が有る(これはJavaでも満たしています)
○対応する変数の型も存在する(Javaに無いのはこっち)
○「クラス」をその変数に代入するとき、継承関係に見合った代入の制限が行なわれる(これもJavaに無い)
だと思います。
Classクラスの各インスタンスは各クラスに対応して存在してるようですが、
それの代入の制御が出来てないんですね。
あ。あと、
○変数の型によって(クラス)メソッドの呼び出し可能性を制御する(これもJavaに無い)
もですね。