アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
これって。。 (スコア: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)以外の選択肢だって
「自分で作れ」で話は済むわけで、
あらゆる批判の意味がキャンセルされるだけ。
>機能的には interface と無名クラスで代用できると思います。
>加えて、それほど頻繁に使用されるわけではないとおもうのですが、
>構文糖を用意する必要があるでしょうか？
RubyやSmalltalkやLispの「言語の力」を見てしまうと、もう戻れません。
身近(??)なところでは、Rubyのイテレータ(と呼ぶと最近はウケないんだったかな)なんかかな。
もし見た意見、もとい未体験なら、ぜひどうぞ。
今まで自分は何やってたんだろう？と目から鱗ですから。
構文糖かどうかは微妙です。
「関数オブジェクト」を作るリテラルだ、と捉える
(つまり関数っつークラスを新設する：たしかまだ無いよね？)ほうがいいかも。
まあ現状の無名クラスの構文糖として実現「してもいい」けど。
Re:これって。。 (スコア:0)
Delphi 風の記法をするためには、クラスメソッドが多態できるだけではだめですよね。
> あらゆる批判の意味がキャンセルされるだけ。
まぁそうですね。
批判が建設的でなかったので嗜めたつもりなんですが。
Re:これって。。 (スコア:0)
ただ単に無知なだけか、もしくはセンスが無いか、のどちらかですね。この発言。
Re:これって。。 (スコア:1)
ん？「Delphi 風の記法」とは、Delphiに数多ある特徴()のうちの、どこまでを指すんですか？
てか、とりあえずここではクラスメソッドの多態の話(だけ)をしてたと思うんですが…
>使ってる言語ごとに頭を切り替えられるようにした方が良いと思いますよ。
それって「妥協しろよ」と言っているに等しいわけで、
かなりショボい意見だと思うんですが。
どの言語の表現力も同じくらいであるならば、
プログラマの頭のほうを切り替えれば話が済むんですが、
実際にはそうではなく、言語には表現力の多寡(や方向性)の相違があります。
その現実から目をそらすのは、プログラマ(あるいはプログラマを使役する人)として
あまり良い姿勢ではないですよ。
というわけで、
>批判が建設的でなかったので嗜めたつもりなんですが。
あなたの言う「建設的」ってのは何なんでしょうか？
妥協することですか？(藁
あらゆるプログラマに、「満足できないなら自分で言語作れ」とまでは
俺も言う気はありません。
が、じゃあ「自分で作れないプログラマは、現状で満足しろ」などという
非道な(^^;こともまた、俺には言えませんね。
仕方なく使うものの不満は不満として持ちつづけることと、その不満すら忘れてしまうこととでは、
人道的(^^;にも大差が有りますし、技術力として見ても(潜在的に)大きな差が有ると言っていいでしょう。
どちらかというと、不満を忘れれば、その不満を解消するチャンスも永遠に来ないという意味で、
潜在的ではあるものの、そちらのほうがむしろ非建設的だと思います。
＃糞環境しか与えず、それで無理矢理書かせることをもって「生産(性)」だと呼ぶような上司には
＃もう飽き飽きしてるのでG7
ところで、建設とか生産とかを考える時には、それが「どこで(誰の手で)」行なわれているか？を
考えないわけにはいきません。
というのは、例えば、プログラム言語が優れていれば、つまり言語開発者の生産が沢山なされているならば、
言語ユーザ(所謂プログラマ)は、同じ結果を得るにしても、そのぶん楽が出来るわけです。
で、プログラム(言語処理系含む)の永遠の真理として、「同じものは一度作れば充分」なわけですから、
一度優れたプログラム言語を作っておいてそれを楽々使うことと、
糞言語を毎回毎回苦労して使うこととでは、
生産性が段違いに違ってくるわけです。
あなた、そこを考えていますか？
…と嗜めさせてください:-)
「戻れません」という言い回しは、(優れた)プログラマがしばしば使う言葉であるようですが、
あれはそれなりに意味(重み)がある言葉なんです。はい。
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:これって。。 (スコア:1)
>あなたが出来ることに関して言えば、そうです。
>他の人であれば他の方法もあると思いますが。
うわ、最低ですね(藁
そういうこと言う人に限って、誰に対してその台詞を吐くかを、自分で(勝手に)決めてしまうわけです。
「与えられた環境」という概念を、なにか勘違いしていませんか？
それはしばしば、
例えば、もし貴方が会社の社長ならば、「貴方が部下に与えたもの」であったり、
例えば、「大手(技術的に優良かどうかは別問題ね)のベンダーが発売したもの」だったり、します。
つまり環境とは、恣意と自分勝手(笑)に基づいて、(力のある)誰かが用意したもの、に過ぎないということが
茶飯事なわけです。
本来そういう場合は、環境を「与えた」側が、色々な責任(例：開発が遅れたときの責任)をとって欲しいもんなんですが、
そういうかたがたは責任をとる時になると今度はトボケるんですよね…
そして、部下に責任を押し付ける…
＃VC++とVBでないと駄目！とかいう要求を出す客や社長をどうにかして欲しいのでG7
＃開発効率を落としたいか？落としてもいいのか？
＃そのくせ遅れれば怒るくせによぉ？
＃つまり彼らは、我々に(価値の無い)妥協を迫るくせに、その見返りとして自分らも妥協することは、決してしない。
ところで。その手の「妥協」ってのは、プログラマにとっては「労働条件(の悪化)」でもあります。
>その部分は、あなたが上司なり同僚なりに説明すべき事でしょう。
>ひょっとして /. 経由で社内コミュニケーションを取ってるのかな？
当然こっちの内輪の事は内輪でやってますが、
それとは別に、一般論としても嗜め(笑)るに値する事柄だし、
もし貴方の思考がそれに該当するというなら、それも嗜め(笑)るに値する、というだけのことです。
自分だけ蚊帳の外に居ようなんて、甘いですよ。
他の人も書いてたようですが、こういう場面で「妥協しろ」って言い出すのは、
確かにセンスも無ければ責任感も無い意見、だと思います。
センスが無いってのは、(もし自分が社長とかならば)自社の生産性に対する嗅覚が欠けてるっていう意味で、
責任感が無いってのは、(もし自分が社長とかならば)自社の存続に対する危機感が欠けてるっていう意味。
------
>あなたが出来ることに関して言えば、そうです。
余談ですが、JavaVM上で動くRubyだのPythonだのLispだのがあるようですので、
それらを使うと、Javaという「与えられた(笑)」環境の中でも、なんとかなる…かも知れません。
というわけで、「あなたが出来ること」をどうやって推し量ったのか、伺いたいものです。:-)
どんな選択肢があるかを知らない人間:-)が、比較的知ってる人間:-)に対し「出来ること」を判断する
ってのは、論理的に考えても、ちと滑稽な議論だと思うんですが。
それとも、JythonやJRubyのInstallを許可しない、という行動に出ますか？(T_T)
…つまりですね、「出来ること」ってのは
「上司が許可してること」の言い換えに過ぎないっていうケースが
多すぎるんですよ。
そういや、
大手が作った製品(JavaとかJ2EE)とかを盲信し、
あと自社の(しばしば糞な)プログラマをも盲信する(笑)くせに、
その中間(?)である程ほどに優秀な世間の第三者製ソフトを一方的に信じない、
という意味不明な行動をする人は、(会社内とかに)棲息してるのをしばしば目撃しますね。はい。
いや、まあ、どういう行動を選択しても自由かも知れませんが、
その選択によって、自社社員(プログラマ)と、自社の利益と、の
両方の首を締めている可能性については、考慮してください。
もしあなたがそれ系の立場のかたならば。
＃そして、そういう立場でないにしても、なにか似たような状況に置かれたら、この話を思い出してください。
Re:これって。。 (スコア:0)
簡単に言うとクラスメソッドの多態を導入するには、
> ClassNameの部分がファーストクラスオブジェクト
である事が必要であるのに Java はそーなってませんよね。
Re:これって。。 (スコア:0)
ここで愚痴ってるのをみて、自力で労働条件の改善が図れないのだろうなぁと思いました。
Re:これって。。 (スコア:1)
○ファーストクラスオブジェクトな「クラス」が有る(これはJavaでも満たしています)
○対応する変数の型も存在する(Javaに無いのはこっち)
○「クラス」をその変数に代入するとき、継承関係に見合った代入の制限が行なわれる(これもJavaに無い)
だと思います。
Classクラスの各インスタンスは各クラスに対応して存在してるようですが、
それの代入の制御が出来てないんですね。
あ。あと、
○変数の型によって(クラス)メソッドの呼び出し可能性を制御する(これもJavaに無い)
もですね。
Re:これって。。 (スコア:1)
問題は、そもそも何故、そんなもん(=言語などの道具の選定)が
労働条件になってしまうのか？だと思います。
(不適切な)言語の採用を強制されてしまうと、それは労働条件(の悪化)に繋がるのですが、
問題は、なんでそもそもそんな強制を「する」のか？です。
仕事の邪魔だから、是非とも黙っていて欲しいんですけど(ただただ黙っててくれりゃそれでいいんですけど)、
余計な「支配」をすることを好む、経営者だの上司だのって、なぜか多いですよね。
なおここでいう「余計」とは、利益に全然繋がらない、それどころかマイナス、っていう事です。
給料の金額みたいに、直接労使間の引っ張り合いのネタにならざるを得ない問題ならば、
どうこう言うのも判るんですが、
社員の道具をわざわざ使いづらいものに替えることがどうして雇用側の利益に繋がるのかは、俺にはわかりません。
ま、アホは自分がアホだと気付かないからこそアホなんでしょうね。
そして、アホじゃない人(もし居れば)は、出来るだけアホを嗜め(笑)る方向に動くわけですが、
アホだからこそなかなか応じないわけで。
あらゆるアホ(笑)に対応(笑)する能力つーか根気は、
たしかになかなか持てませんよね。
いや、無限の時間と手間をかけても尚無理なんじゃないかな？
＃そりゃ頭悪い人間も飯を食うために仕事するんだろうけど、周囲にとっては純粋に迷惑なんで、どうにかして欲しいG7
で、俺に出来ることですか？
アホがアホな命令をしなければ(笑)、俺が出来ることはいろいろ有ります、ってゆーだけのことなんですが。
アホがアホな命令をすることを止める手段は、俺も確かに知りたいですね。
Re:これって。。 (スコア:0)
ちなみに、ここで愚痴るのは利益に繋がるんでしょうか？
あ、ストレス解消できればマイナスではないのかもしれません。
Re:これって。。 (スコア:1)
スラドユーザにとっては、利益なんて関係ありません(^^;