Carbon版HyperCardを騙ろう - 1067262136

1：ぷご：2003/10/27(月) 22:42: Xcode+CarbonでOSX用のHyperCardを作ってしまえ！
という構想はあるものの、そこまでの能力と時間と資金は
ありません。というわけで、構想や妄想や感想や暴走を
繰り広げてみようというスレッドです。

いけそうだと思ったら本気で作るかも。
2：ぷご：2003/10/27(月) 22:54: Q.なぜにXcode？
A.無償、最新、Carbon対応だから

Q.Cocoaはどうした？
A.ObjectiveCでは移植が困難になるため。純粋なCを使う。

Q.移植というのはWindowsへの移植？
A.それも含めて、Palm、UNIX、Classicなども考えられる。
　選択肢は多い方がいい。

Q.本気？
A.考える事自体が面白い。それに考えるだけでも意義はあると思う。
　今できなくても、将来できるかもしれない。
3：ぷご：2003/10/28(火) 22:48: ●基本設計
本体は中間言語インタープリタとして動作する。
HyperTalk風言語を中間言語にコンバート。（スクリプト保存時に行う）
変数には数値（double型）と文字列を格納できる。
テキスト、画像、サウンド、ウィンドウ、メニュー、ファイルなどを扱える。
本体そのものはGUIを持たない。GUIは中間言語とリソースで作る。

中間言語にすることで高速性、柔軟性、移植性、拡張性などバランスのとれた
ものにできる。C言語に匹敵するほどの速度は必要ない。
4：ぷご：2003/10/28(火) 22:57: ●過去との互換性
HyperTalkをベースにした言語を使えるようにする。
HyperTalkから簡単に変換できる程度のもの。

カードピクチャやボタン、フィールドのデータやプロパティは
コンバート用のHyperCardスタックを作ってリソースに書き出す。
どのような構造になっているのかはXMLあたりで記述したいなぁ。
5：ぷご：2003/10/28(火) 23:02: ●ペイントを基本に
MacOSXではアンチエイリアスが多用されており、
これと相性のいいのはドロー形式なのだろうが、
ペイントの方が分かりやすいため、あえてペイントを
基本にしてデザインできるようにする。

液晶の解像度が今後大きく上がるのではないか？
そのとき、アンチエイリアスは不必要になるだろうと
考えている。僕個人としてはそうなってほしい。
6：ぷご：2003/10/28(火) 23:10: ●フィールド
テキスト編集機能をどう実現すればいいのかは悩むところ。
表示だけならHTMLを表示するのが良さそう。
Webをそのまま表示できれば便利だし、案外楽に組み込めそうに思う。

でも、やはり普通にMLTEを使うべきかな。
なるべく自前での実装はさけたい。
7：ぷご：2003/10/28(火) 23:14: ●アプリケーション化
スタックデータはすべてリソースに持つことになるので、
アプリケーション化といっても特別なことをする必要は
あまりなく、リソースを組み込むくらいで良い。

ちなみに、１アプリケーションで複数のスタックを開くことはできない。
１アプリで１スタックに対応させる。
8：ぷご：2003/10/28(火) 23:23: ●開発方法
いわゆる「オープンソース」の開発では、
開発者自身の興味や技術的な面にばかり
力が入ってしまう傾向があるように思われる。
HyperCardにはそれは似合わない。

ビルアトキンソンは何を考えながらHyperCardを
作ったのだろうか？

ベース部分は一人で作らないといけないだろうと思う。
9：ぷご：2003/10/29(水) 19:48: 昨日分を修正
・スクリプトは保存時コンパイルではなく、実行時コンパイルとする
・複数のスタックを同時に開くことはできないが、ライブラリ化は可能。
　リソースとスタックスクリプトを扱える。
10：ぷご：2003/10/30(木) 23:26: HyperCardでは視覚効果は大したことはできなかったが、
いまのCPUではかなりのことが可能。ページめくりくらい欲しい。

カードだけでなく、ボタンやフィールドの表示/非表示でも
視覚効果を付けることができる、のは作るの大変そう。
11：ぷご：2003/11/01(土) 15:24: 中間言語はBASIC的なものになると思うんだが、
それではあまり良くない。魅力に欠ける。
とは言っても速度面とシンプルさ、分かりやすさの
バランスが必要なので凝った事は出来ないしなー。

GOTO文はさすがに作りたくないので入れませんが。
ifとrepeat、next repeat、exit repeatでできるでしょ。
12：ぷご：2003/11/01(土) 15:50: プロジェクトは名前が重要だと思ってみたりする。
mirageとかいうXCMDはその名の通り蜃気楼のように消え去った。

というわけで、現在の案
中間言語実行アプリ：「MacRoke」（まっくろけ）
中間言語：「未定」
高級言語：「未定」
RAD型開発環境：「未定」

未定だらけだ。
13：ぷご：2003/11/01(土) 20:08: mallocとfreeで文字列変数を確保しようと思っていたのだが、
Poolを作って1024byte単位で確保とかしたほうが良さそう。
メモリの断片化&メモリの再確保による速度低下を防ぐわけ。
14：ぷご：2003/11/01(土) 21:26: 変数名から変数の中身を取得する部分や、
関数名から関数の内容（スクリプトだから単なるテキスト）を
取得する部分はリストの単純サーチで作ればいいと思っていたのだが、
速度低下が激しい気がする。

静的リンクは無理としても、せめて１度参照したものだけでも
静的リンクに出来ないものか？

いや、あまり変な実装するのはやめておこう。
最初は出来るだけ単純な構造で作り上げ、その後
パフォーマンスが悪いところを集中的に改善するほうが
良い結果が得られる。最もシンプルでデバッグしやすい作戦でいこう。
15：ぷご：2003/11/01(土) 23:16: リソースをいろいろ扱えるようにしたい。
Carbon版のResEditが作れるくらい。

それができれば、それだけでも存在価値はありそう。
スクリプティング可能なリソースエディタだなんて！
16：ぷご：2003/11/02(日) 01:43: ゲームを作る事はあまり考えないようにする。
ゲームを作れるだけのポテンシャルを持つ基盤にしなければ
ならないが、ゲーム以外が作れないなら意味が無い。

教育分野で使える、とすれば魅力なんだが使われるとも思えないし、
便利ツールが作れる、プロトタイプが作れる、というところで
適当に落ち着かせよう。高度な開発環境ならXcodeがある。
便利な開発環境が足りないんだ。