|
[最近のツッコミ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| [全文検索] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ☆基本的に個人的なリンク集、偶に思い出したように文章を綴る日記。 ☆JAVA・Ruby・RELAX NGネタ中心です。O:原文,P:ポップアップ辞書,t:和訳 ☆[category]:カテゴリフィルタ画面 ☆[blogger]:Blogger出張所。徒然。 ☆[kuro]:個人的ライブラリ開発プロジェクト「Kuro Project」サイト。 ☆[kuro-pj]Kuro Project開発日誌。 ☆[ruby]Ruby学習日誌。 ☆[vox]:VOX出張所。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CVSの後継を目指し開発中の新VCS"Subversion"(on off)用のプラグイン。現在はIDEA3.0用のみ存在。
Subvesionのクライアント用ネイティブAPIをJNIを利用してラッピングしたライブラリ"svnup"を利用、
linux及びWindowsに対応。
[参照]
http://subversion.bluegate.org/
http://www.atmarkit.co.jp/flinux/special/webdav03/webdav02a.html
http://ma2tak.dyndns.org:8888/ma2tak/1144
http://www.cozmixng.org/~kou/linux/svn
http://www.atransia.co.jp/home/ZenKai/Members/kafka/News/1036945331/newsitem_view
http://w3.cube-web.net/eclipse/index.php?%5B%5BSubclipse%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3%5D%5D
「私がJavaからC#に乗り換えた10の理由」(on off)...「乗り換えない理由」を整理してみる
(1)開発元がマイクロソフトだから
マイクロソフトの開発環境に下位互換性は期待できないから...。VB...Access...然り。
(2)"闇鍋"のようだから。
便利だと思われる機能を闇雲に取り込んでいるので、一貫性がなく、取捨選択がないので
改訂の度に際限なく、仕様が膨らみそうなので。
(3)ワクワクさせてくれるようなコミュニティがないので
新しい方法論等の実験的な実装に利用されるような土壌がC#にはない...、これからも
存在しえないだろう。
(4)ブラックボックスの塊だから
JavaVMはそれ自体の仕様とソースが公開されているけど、CLRの場合はとってつけた
ような仕様しか公開されていない。
エクスプローラのシェル拡張。エクスプローラにSubversionクライアント機能を付加します。
リポジトリの作成から始まる一連の操作をエクスプローラ上で行えるので非常に便利です。
※Subversion専用クライアントとして開発中のRapidSVN(on off)もありますがこちらはアルファステージです。
"文法や構文"はISO標準として発行されましたが、"処理系"に関わる部分はまだまだです。
これじゃぁ"C#はISO標準"なんていえませんね、ホント。
M$が特許で縛ってる限り"処理系"に関わる部分がISO標準になることはありえませんな。
#Raeva(?)からツッコミ(on off)があったので捕捉しておきます。
CLIも部分的にはISO標準(on off)になっているようです。
何故、部分的かというと、実際の実装に必要な情報の多くが欠落しているようにしか見えないからです。
「CLI=C#の処理系」とはいえません、。確かにC#はCLI上で動作しますが、C#のソースをどのように処理して
CLI上に展開するかという情報があってはじめて、CLIとC#の間に関連性が生じます。
CLIで承認されているのは下記だけです。これだけの情報でM$と互換性のある実装が可能でしょうか?
1)概念と構造
2)メタデータの定義と意味論
3)CIL命令セット
4)プロフィールとライブラリ
5)捕捉
Rubyにはある。純然たるオブジェクト指向言語ではメソッドもオブジェクトと扱う必要があるらしい。
手続きには実体がないのだから、手続き(=メソッド)をオブジェクトとして扱うのは如何なものか?
オブジェクト指向的に手続きもオブジェクトとして扱えるほうがすっきりするというのはなんとなく
わかるんですが...。
メソッドをオブジェクトとして扱う場合、ガーベージコレクタVMにおいてどのように扱うのかが問題のような気がします。
VM化するRuby2.0もまだ影も形もありませんし...。
Javaにメソッドオブジェクトを導入する場合、下位互換性を維持できるのか?
維持できなければ、"メソッドオブジェクト"はJavaには導入されない...。
"メソッドオブジェクト=Methodクラスのオブジェクト"とのこと。言われてみれば当たり前なんですが...。
Javaに導入される場合、全てのメソッドが対象となるのではなく、Methodクラスを継承した
メソッドオブジェクトが従来のメソッドとは別に定義できるようにすれば、つまり
従来のメソッドとは異なるメソッドオブジェクト用構文を導入すれば、互換性の問題はクリア
されるような気がします...。全てのメソッドをメソッドオブジェクトとして扱う言語と比較すると
違和感バリバリですが。
# miki [Cute PDF使ってみました。日本語を含んだWord文書もOKでした。]