5月2008

[本]詳解 Objective-C 2.0

地元にある行きつけの中規模な本屋に、詳解Objective-C2.0が早速入荷されていました。それほど多くの本を置いていな本屋のなのに、このような本を置いてくれるとは、やはり毎週いくだけの価値のある本屋です。

4797346809 詳解 Objective-C 2.0
荻原 剛志
ソフトバンククリエイティブ 2008-05-28

by G-Tools

この本は、Objective-C Mac OS Xプログラミングを、Objective-C 2.0に対応した形で再版した本です。旧書に比べ、ガベージコレクション、プロパティ、高速列挙、このあたりを中心に内容が追加されていますが、他にもさまざまなところで追加されている部分があります。例えば、アンドゥマネージャやバインディングとか、結構細かい所での追加があったりします。もちろん、この本はObjective-C 2.0が中心ですので、AppKitの範囲の説明にはほとんど至らないので、バインディングの説明といってもInterface Builderとかの話は入りません。

旧書同様に、Objective-Cを始めるにあたっての必読書になるでしょう。iPhoneとかに興味を持ってしまったMacユーザー以外の方も、読んでいて損は無いでしょう。iPhoneの開発環境はObjective-CでCocoa touchを使うことになります。ちょっと値段が高いですが、この一冊さえあればObjective-Cを使うにあたって困ることはなさそうなので、常に手元に置いておきたい本です。ちなみに、この本を読むにはC言語の知識があること前提ですが、オブジェクト指向の知識は必ずしも必要ありません。

ところで、ちらっとNSUndoManagerのところが目に入ったわけですが、NSUndoManagerには- prepareWithInvocationTarget:と呼ばれるC++にも劣らないような恐ろしいメソッドがあることを知りました。NSUndoManagerもとてもユニークなクラスであるようなので、後日記事にしようと思います。

Objective-C++

私がこれまでにメインで使ってきた言語は、ActiveBasicとObjective-Cなわけですが、これら2つはどちらもマイナーな言語です。というわけもあり、最近C++の必要性を感じてきたこともあって、C++をこれから覚えようかと思っています。もちろん、Cを含めた標準ライブラリもほとんど触ったことが無いので、STLくらいまでは使えるようにしたいと思っているところです。

そういわけで、ちょっとC++を触ってみたわけですが、やはりObjective-Cとは正反対の感覚を感じます。C++はテンプレートという文法取り入れ、コンパイル時に全ての型のコードを展開することによって、データ型にとらわれないプログラミングを行うことができるのに対し、Objective-Cは、特にこれといった文法は取り入れず、動的なメソッド解決によってデータ型にとらわれないプログラミングを提供しているからです。どちらが優れいてるというわけではありませんが、C++は頑張っていて、Objective-Cはさぼっている言語のような気分を抱かなくはないです。

ところで、C++とObjective-Cのコードを同時に書くことのできるObjective-C++というものがあります。想像するだけでもかなりカオスな状態になりそうで、一体誰が使うのだろうかと思うわけですが、Web Kitの一部でObjective-C++が使われているらしいです。

参考資料:C++ と Objective-C の併用

プロパティについて補足

前回のプロパティの微妙なところの記事の補足です。

他の言語でもおそらく、今回問題にしていたプロパティのsetter、「オブジェクト.構造体.メンバ」というのはできないと思います。それで、なぜObjective-Cで違和感を感じているかと言えば、「オブジェクト.オブジェクト」のsetterは書くことができるからです。具体的には、Appleのドキュメントからの引用ですが、

person.address.street.name = @"Oxford Road";
[[[person address] street] setName: @"Oxford Road"];

インスタンス変数がすべてオブジェクトの場合、.構文は正しいメソッドに展開されます。

.構文について表にするとこうなります。

getter setter
オブジェクト.構造体.メンバ ×
オブジェクト.オブジェクト

このように、対称性が取れてない部分があったために、違和感を感じてしまったわけです。


最近記事が手抜きになってきてる気がします。。。RSSを購読して期待してたりする方には申し訳ないですね。

プロパティの微妙なところ

Objective-C 2.0でプロパティが導入され、簡単にアクセッサが書けるようになったりしましたが、やはりこのプロパティという文法は、言語としての美しさを少し損なって成り立っているように見えます。

というのも、次のようなコードの場合です。layer.positionの戻り値は、点を表すCGPoint構造体であり、float型の{x,y}メンバを持っています。

CALayer *layer = [CALayer layer];
float x = layer.position.x;
layer.posistion.x = x;

全く意味のないコードではありますが、この一番最後の行に問題があるのです。実は、最後の行のようなコードを書くことはできません。なぜなら、.を使った構文は、以下のように展開される仕様だからです。(展開のされ方は私のイメージです。)

CALayer *layer = [CALayer layer];
float x = [layer position].x;
[layer position].x = x;

そういうわけで、私はプロパティをメソッド生成の時にしか使わず、.を使った構文は使う気がありません。

参考資料:Objective-C 2.0プログラミング言語 > プロパティ

途中まで記事を書いたものの…

そろそろCocoaバインディングの記事を書こうと思って、さっき1時間くらい書いていたのですが、どうも納得できる記事になっていないんです。やはり面倒がってGimp使って図を描いて挿入しなかったのが原因か…それとも、最近また作り始めているWEBサイトの記事が固すぎるために、ブログの文章がきれいに見えないのか…

おそらくCocoaバインディングの記事は、読む人が多くなるだろうと思うので、しっかりとした記事を書いておきたいです。

Code Reading借りてきた

とある図書館でCode Readingという本を借りてきました。数年前から読みたかった本のひとつですが、なかなか置いてある本屋がありませんし、なにしろ本の値段が高額ですから買うこともできません。というわけで、これから2週間後には返さなくてはいけないのですが、焦って読んでもしょうがないので、そのときはまた後で借り直したいところです。

4839912653 Code Reading―オープンソースから学ぶソフトウェア開発技法
トップスタジオ まつもと ゆきひろ 平林 俊一
毎日コミュニケーションズ 2004-06-01

by G-Tools

ADCのリファレンスが見やすい理由

Mac OS Xのプログラミングをやっていると、やはりドキュメントの数の少なさに苦労することがよくありますが、しかし、Appleの公開しているドキュメントは豊富で、必要な情報が見つけやすいと思います。というわけで、その理由を探ってみようと思います。

今回は、クラスリファレンスのページを見ることにしましょう。巨大なNSStringクラスを例にとってみます。

reference

ADCのリファレンスが見やすい理由は、以下の2点だと考えます。

  • そのクラスの使い方を記すガイドにリンクしている
  • メソッドがタスクごとに分類されている

まず一つ目の、ガイドにリンクしているというのは、”Companion guides”のところです。このリンクは各クラスのほとんどのページにあり、たとえクラスの使い方がわからなくてもガイドを見ればたいてい解決します。

二つ目は、メソッドがタスクごとに分類されているということですが、これは左側のフレームのTasksのところです。これの分類があるおかげで、目的のメソッドを素早く探し出すことができます。また、Tasksを見ているだけで、このクラスが具体的にどんな機能を持っているのかを、簡単に把握することもできます。

まあこんな感じで、どうでもいいようなことを言っているように思われるかもしれませんが、実際にリファレンスを引くとなると、そのわかりやすさを実感できるかもしれません。ちなみに、Companion Guidesのドキュメントが非常に優れたドキュメント群であることを忘れる訳にはいけません。リファレンスを書くようなことがあるときのお手本になりそうです。

投稿者コメントのダウンロード

少し前の話になりますが、ニコニコ動画には投稿者コメントという機能が追加されました。今回はそれのダウンロード方法です。

POSTリクエストの中身を調べればすぐにわかりますが、通常のコメントダウンロードのXMLの属性に、fork=”1″を追加するだけで、投稿者コメントのダウンロードができるようです。

つまり、こんな感じです。

<thread thread="**********" fork="1" version="20061206" res_from="***" >

通常のコメントダウンロードの仕方については、ニコニコ動画のコメントをダウンロードをご覧ください。

デバッグ実行は遅い

まあ、当たり前の話ですね。情報や操作の多かったりするデバッグビルドの実行よりは、それらが入っていないリリースビルドの方が実行はある程度速い訳です。ちなみに、ActiveBasic5.0はデバッグとリリースの実行速度にかなり差があったような気がするので、注意しましょう。

なぜ今更こんな話をしているのかと言えば、どうしてもパフォーマンスが改善されず、マルチスレッドを使わざるを得ないかというところで、とりあえずブログのネタにしようとリリースビルドし、スクリーンショットを撮ろうとしたところ、デバッグビルドに比べて、リリースビルドはほぼ問題ないパフォーマンスで動作してくれたからです。

やはりiBook G4にCore Animationは厳しかったか、という記事を書こうとしたのですが、それはお預けになりそうです。

n_Player beta

ただ、たまに文字の長さが長すぎると、”Core Animation: image is too large for GPU”と悲鳴をあげ、きちんとレイヤーが描画されないことがあります。

ところで、スクリーンショットのあれは、ニコニコ動画のプレーヤーです。去年プロトタイプを一度作ったことがありましたが、それとは完全に別物で、こちらはきちんと設計し、コメントの配置も、基本的にはコメントをできるだけ画面上に重ならないように表示する、というように実装しています。まだ細かいところは実装が必要ですが、ある程度形になっています。

環境設定…でカラーやフォントも即座に切り替えることができるようになっていますが、このような環境設定パネルが思いのほか簡単に作れることがわかったので、あとで記事にしようかと思います。

Preferences

あまり関係のない話ですが、ヘルプを見ても名前から実際の色が今ひとつ浮かびません。私の想像では、暫定的に上のような色を当てていますが、、。ヘルプに色を載せておけばいいのに、と思います。

.NET Frameworkのセキュリティ

.NET Frameworkを動作させるときには、その実行場所がどこなのか注意する必要があります。なぜなら、ネットワーク上に実行ファイルが存在していると、実行できる動作が制限されるからです。

例えば、C++のCLRプロジェクトをネットワーク上に保存しようとすると、プロジェクト作成の際に警告のメッセージが表示されます。C++の場合はCLRプロジェクトを作成しても、ネットワーク上に存在していると実行できないからです。

しかしC#では、ネットワーク上にプロジェクトを作成しても、一部の制限をのぞき、問題なく動作してくれるようですが、プロジェクト作成の際に警告は出ないので、例外が発生しても何が原因かわかりにくいです。

そういうわけなので、.NETのプログラミングではプロジェクトの作成場所に注意を払う必要があるようですが、今のところこのことがMSDNのどこに書かれているのかがわかりません。従って、詳細も不明なので、.NETプログラミングする人は、とりあえずプロジェクトはローカルな場所に作成した方が良い、ということだけ覚えておいた方がいいでしょう。