ひとりごち 2011

過去の独りごち/独りごとはこちら
過去のJavaアプレットはこちら

12/20 Delphian in Cupertino

　(お知らせ) 現在、BBSに書き込みキーを設けています。「書き込みキー」欄に、「MYOMOTO」をカギカッコは抜いて、半角、小文字で 打ち込んで書き込みをしてください。このキーワードは時々変更されますが、その都度こちらにて報告します。

　以下、本文

　MacBookAir用にフォントをいじってみました。美しい美しいと評判のヒラギノフォントは良いですね。早いところWindowsにもメイリオ以外のClearType対応のフォントを標準装備して欲しいものです。

　iOS,MacOSX用のプログラミングを初めました…と言っても、とりあえず環境を整備せねばなりませんでした。なにしろMac自体はじめてですから。とりあえず、毎日使うようなソフトというと、

Webブラウザと2chブラウザ
IDE
GOw
NobileArm
見る人
時々Photoshop

　くらいなのですが、ブラウザとIDEはすぐにクリアできたのですが、自作ソフトの代替はどうしたものかと思いました。しかし、OS Xのシェルが非常に強力でして、GOwのディレクトリ検索機能はOSに最初からついてくるspotlightがGOwの上位互換になり、ホットキー型のランチャーとしてはフリーソフトのSparkとAppleScriptを組み合わせることでクリアできました。NobileArmの代替はこれもOS標準のDockのスタックを使えばOK。本当に気が利いてます。

　で、「見る人」の代わりにOS標準のプレビュー機能…と思ったのですが、同一フォルダ内のファイルを順次表示してくれる機能がない。そんなわけで、「見る人」だけ移植することにしました。半透明機能と回転機能は実装してませんが、NSImageクラスが異様に強力で、アニメーションGIFの再生にも対応できました。特にアニメGIF対応のためのコードは書いてないんですが。更に、PSDファイルも普通に読み込んで表示してしまうというのが凄い。回転機能もNSViewの機能で簡単に実現できるようなので、気が向いたら付けてみようかとも思っています。

　あとはPhotoshopでしょうか。こんな日のためにPSEはmac/win両対応のパッケージを買っておけばよかったのかもしれませんが、Windows用に買ったのはPSE8ですし、Adobe製品のライセンスはなにやら雲行きが怪しい事になっているようなので、代替ソフトを検討しています。年賀状の作成までにはなんとか…。

　で、目下のところ、Objective-C 2.0(以下、単に「Objective-C」と書きます)そのものの勉強をしています。Xcodeを使ってのビルドの方法とかのツールの使い方は最初の一歩くらいは分かってきたので、とりあえず言語仕様と標準ライブラリの主要なクラスとかについてある程度把握しておこうかという事で。

　Objective-Cの第一印象としては、C++よりもむしろObjectPascalに近いような感じがあります。やったね。「やったね」と打とうとしたら「やったねたえちゃん」が候補に出てくるあたりGoogle日本語入力マジ快適なんですが、それはおいといて、C++は構造体の拡張としてクラスを定義しているような印象があるのですが、Objective-Cでは、クラスはあくまでクラスであって、構造体とは全く異質な物である、という意志を、その構文から感じます。メソッドの呼び出しもC++では

obj->method();

　という調子で「メンバ関数を呼ぶ」という感じであるのに対して、Objective-Cでは

    [obj method];

　というような書き方で、「これからobjにメッセージを伝えます」「えーと、methodで。よろしく」「以上」という感じです。ちなみに、Objective-Cではメソッド呼び出しの事を「メッセージ」と呼ぶのが普通のようです。メソッドはメソッドですが、「メソッドを呼び出す事」＝「メッセージを出す」なんですね。

　それから、Objectve-Cではプロパティをサポートしているため、読み出し専用メンバを作りたいからと、メンバ変数ごとにgetなんとかsetなんとか、というメッセージの山を用意しなくてもいいそうです。ただし、デフォルト配列プロパティに相当する構文はありません。その代わり、

    @interface MiruhitoFileInfo : NSObject
    {
        NSString   	*filename;
        NSDate		*filedate;
	NSImage		*icon;
    }

    @property (setter = setFilename:) NSString	*filename;
    @property (readonly) NSDate	*filedate;
    @property (retain) NSImage *icon;

    -(void) setFilename: (NSString*) fname;
    @end

　こんな感じで、(setter)とか(retain)とか(readonly)いうところに、代入ができないのか、あるいは代入や読み出しが生じた際に使うメソッドは何なのか。と、ここまではObjectPascalと同じですが、プロパティがオブジェクトだった時は、「参照だけコピーする」「中身もコピーする」「参照だけコピーし、参照カウンタも増やさない」といった設定が可能になっています。そう、COMのような参照カウンタによるメモリ管理システムが言語レベルで存在します。メモリ管理方式は参照カウンタによる管理、ガーベジコレクションによる管理、そして最近導入されたARC(自動参照カウンタ)による管理があるようです。これからはiOSでの軽量化とコーディングの効率化の両立という点からARCが主流になるようですから、なんか気持が悪いのですが楽そうなのでARCに頼ることにします。

　また、文法自体はJavaやC#と異なり、Cの上位互換だそうです。Cで書けることはそのままObjective-Cでも書けるので、Cを覚えていれば論理演算子とか代入演算子とかを覚えなおす必要はありません。僕はあんまり覚えてないのでちょくちょくリファレンスを引いています。特に優先順位とか。ちなみに演算子の多重定義はできません。そのため文字列クラスとかがめんどいです。でも基本的にUnicodeで統一されているのには非常に使い勝手がよく感じます。

　言語仕様上の違いではなく、フレームワークの違いですが、これはひしひしと感じます。特に、Mac OS X用フレームワークであるCocoaではイベントハンドラの設定が煩雑に感じます。Delphiで言う「TButton.OnClick」程度の事はターゲットアクションメカニズムを用いてインターフェースビルダからサクサクと指定できるのですが、それ以外については

デリゲートを利用する
イベントハンドラをサブクラスで定義する
KVCを使ってキー値監視や通知を利用するようなコードを書く

　実は色んな方法があって、どれもが柔軟性に富んだ強力な方法なんですが、インターフェースビルダーの画面だけでは個々のコントロールがどんなイベントに対応するのか、という事が一望できないんです。リファレンス読みたくない。KVCとCocoaBindingなんかはインターフェースビルダだけでほとんどなんでも出来るようにしちゃろう、という気概をひしひしと感じるのですが、DelphiやVBに慣れてる人間としては「コレじゃない」感が強い気がします。でも、UserDefaults(レジストリとかiniファイルみたいなもの)とのやりとりは楽チンです。ウィンドウの位置・大きさとか、ダイアログでの設定項目を保存するのに何もコードを書く必要がないなど、面倒な点を我慢する価値はあるかも…と思ってしまいます。

　ちなみに、Xcodeには面白い機構があり、インターフェースビルダーで配置されたコントロールに対して「中身はワシが育てたサブクラスじゃ」と断り書きをすることが出来、自前で定義したサブクラスを使えるのです。コントロールのサブクラスを定義するのが前提の設計になっているので非常に強力なカスタマイズ性とエレガントなコーディングを両立していると言えます。実際、一個のフォームの異なるコントロールに出される個々のイベントハンドラがズラズラ並ぶユニットに比べると、コードはすっきりしたものになります。よく使うイベントハンドラの種類を覚えるまで面倒そうですけどね…

　実際にはもっと簡単で直感的な方法があるのかもしれません。日常に供するソフトとしては、やはりiPhone用よりもMac用として作ったほうが快適そうですから、Cocoaの勉強ももう少ししてみたいところですね。

　しかし、iOSのUIKitでは一変して、ターゲットアクションメカニズムをより一層活用する向きになってます。これにより、OnClickのような物以外にも色んなイベントを一覧から選ぶという事ができるため、ほぼDelphi感覚でプログラミングを行えます。加速度センサやGPSなどのDelphiでいうところの「非ビジュアルコンポーネント」の活用にはデリゲートを使うため、ある意味Delphiより楽なコーディングができます。Cocoaも将来こういう風にならないものですかね。

Taku Hayase(SANDMAN)

戻る