X上のRAD環境と言ってしまっていいだろう。たしかに、Objective-Cで組むよりも早くて少ない手数でプログラムを作れる場合が多い。Studioで作成している。Builderには遠く及ばない。OSの頃を考えると「夢」のような開発環境が無料で手に入ることは無上の喜びである。Xが登場してからもういいかげん7年近く経過しており、かつての「夢」は常識的かつ日常的な光景となった。美人で気だてのやさしい彼女でも、結婚すれば一緒に居るのが当たり前になるし、怒鳴り合いの1つや2つはすることにもなる(ウチは怒鳴り合いをしすぎだという指摘もあるが^ー^;)。Studioに話を戻すが、ようやくたどりついた素晴らしい「約束の場所」にも、住めば住んだで喜んでばかりもいられない「現実」というヤツが横たわっていたりするのである。Viewの......と、オブジェクト階層を書く場合に、すべて手で書かなければならない。このあたりは、初心者にとってはある意味Objective-Cによる開発よりも過酷と感じられるかもしれない。熟練者はGUI部品への参照を書くのを省略する方法を知っている。Nibのイベントハンドラで、GUI部品への参照をグローバル変数に突っ込んで保存しておくという手だ。すれば、部品名を変数で指定すればよく、いちいち長ったらしい参照を書く必要もなくなる。Xcode上で編集中のスクリプトの編集支援機能がない謎きょうび、ScriptEditorをAppleScriptからコントロールして、編集中のAppleScriptに対して支援を行うなどは朝飯前の時代である(実際にやっている)。Script記述をAppleScriptを使って確実で楽なものにすることが可能となっているのだ。した編集支援スクリプトを用意しているのとしていないのとでは、開発効率は雲泥の差ほどもついてしまう。ところが、Xcode上で同様の開発支援を行うことができない。XcodeのAppleScript対応機能がたいへんに貧相なためだ。Editor上で書くようにしているのだが、Xcode上でしか書けない命令などもある。Studio上でVBによるアプリケーション開発を行うイメージに近い。RAD環境として期待してXcodeを起動して、うんざりするほど多いXcodeのメニュー項目に打ちのめされる初心者は多いはずだ。するほど多いメニュー項目の9割以上がAppleScriptによる開発を行うだけなら「不要」なものであり......こうしたメニュー項目を隠すための機能がXcodeにないのは不思議を通り過ぎて不可解である(実は、Xcodeのプラグインを書くとメニュー項目を新設したり隠したりすることは可能だ)。Editorを大幅に下回るデバッグ機能にうんざりさせられる。あろうことか、Scriptの規模が大きくなってくると、この「最低の」デバッグ機能すら効かなくなり、ブレークポイントや変数のモニタリングが効いたり効かなくなったりする。バグの所在を認めたためだろう。Leopardのリリースまでに直っているとよいのだが......。Studio上では「button」と呼ばれるオブジェクトである。この名称の不一致にイライラさせられる(一覧表の資料を作って乗り切ったけど)。いえば、AppleScriptから確認出来る各種プロパティをインスペクタで確認できない(一度テストビルドして、そのアプリを外部からAppleScriptでコントロールしてプロパティを確認したりして乗り切った)。Builderにまったく存在していないのが不思議でならない。OS(日本語)」にしないとビルドが通らない。AppleScript書きにはお約束の作業だが、そんなんマニュアルにもどこにも書いてねーー。Mac上でプロジェクトを一度保存しクローズするとデフォルトのエンコーディングを忘れやがるようになった。Xcodeの開発担当は相当におバカで健忘症なのに違いない。Editor上でスクリプトはUnicodeで扱われるようになった。Studio環境に反映されていないのである。これはどーゆーことなのか。オブジェクト構成、命令等がFaceSpanとものすごく互換性が高い謎サードパーティのソフトウェアであるFaceSpanの命令体系とほぼ同じというか、まんまパクってきたとしか思えない構造は一体どういうことなのか。1994年のAppleScript登場時の開発キットの中にFaceSpanが含まれていたことを考えると、FaceSpanそのものがサードパーティとAppleによる協力体制のもので開発された可能性は否定できない。しても、その知的財産所有権とかってどーーなっているのかものすごく不思議。Studio最大の謎である。