kikerogaさん、ご意見ありがとうございます。
> HSP導入済を前提に考えてましたが
そういえば最初に提案された資料にそう書いてありましたね。
> ソースファイルやデータファイルを移行すればOK
たしかにコードとデータのみの配布だけで完結できたら、
クールでいいなあ、と思います。
---
Y_repeatさん、ご意見ありがとうございます。
> 自分の予定だとCのコードジェネレータぽくしたいので
C言語へのコードジェネレータ、いい考えですね。
私も以前に、
Javascript風のコードをHSPコードに変換する、
コード変換器を作ったことがありました。
http://dolphilia.github.io/althsp/
正規表現を使って、
無理やり置き換えするというもので、
速度と精度の面で難がある、
いわば失敗作なのですが。;^^
---
クリーンなHSPについて、考えたことの続きです。
1. 対象となるユーザー層は？
2. オブジェクトファイルを生成するべきか
3. フィードバックに関する葛藤
4. クリーンさを最重要視すると仮定した場合の考え
5. 必要最低限の拡張
---
1. 対象となるユーザー層は？
クリーンHSPの対象とするユーザーはどのような人たちなのでしょうか。
HSP経験者でしょうか。
- HSPユーザー
- 非HSPユーザー
プログラミングをどの程度たしなむでしょうか。
- 初心者（プログラミングは初めて）
- 初級者（少しは触ったことがある）
- 中級者（ある程度の作品を作ったことがある）
- 上級者（業務あるいは趣味として日常的に書いている）
私は「非HSPユーザー」で「プログラミング初心者」を想定していましたが、
（それで「スマホでゲームが作れる」などの提案をした次第です）
もしかすると、むしろHSPのヘビーユーザーを対象しているのかも、
とも思い、考えが揺れています。
---
2. オブジェクトファイルを生成するべきか
本家HSPはaxファイルを生成します。
そのようなわけで、
クリーンなHSPも、それに倣うべきとは思いますが、
生成しないパターンについても考慮しています。
オブジェクトファイルを生成しないメリットは、
セキュリティが若干向上することです。
オブジェクトファイルが汚染されている可能性を、
チェックする手間が省けるからです。
オブジェクトファイルを生成するメリットは、
速度が向上することと、
実行エンジンの実装が若干簡潔になるです（たぶん）。
---
3. フィードバックに関する葛藤
クリーンなHSPの成果を、
本家にフィードバックしたいという思いと、
その難しさの間で葛藤があります。
本家のOpenHSPに直接コミットするのが、
一番手っ取り早い方法だと思います。
とはいえ、
全く別のプロジェクトとしてフォークしてしまった方が、
作業はやりやすいと感じています。
しかし、そうなると、
本家HSPでの更新を手動で反映させなければならなくなる、
という課題が出てきます。
そしてそれは、元のコードを改変すればするほど、
難しくなっていきます。
本家HSPと足並みを揃えたいという思いはありますが、
現実的なところ難しいので、そこは妥協するしかないのかな、
と考えています。
何か良い方法があるでしょうか。
---
4. クリーンさを最重要視すると仮定した場合の考え
前スレッドで「機能拡張はしない」とありましたが、
ここは仮に、クリーンさを最重要視するものと仮定して、
考えを進めてみます。
前スレッドでダウンロードできる、
sakuraさんの作成した資料を見ていると、
よりクリーンにできそうな仕様がいくつか見つかります。
例えば、カレント情報を扱う命令を挙げると（posなど）、
新たに、サイズのカレント情報を扱うsize命令があっても良いような気がします。
他に、font命令は、
第3パラメータに16を指定することでアンチエイリアシングを指定できますが、
それをくくり出して、smooth命令などに置き換えるのは、
クリーンなやり方のように思えます。
スムージングのカレント情報とも捉えることができるので、
line命令などにも適用できるからです。
---
5. 必要最低限の拡張
- OS情報の取得
- HiDPIへの対応
上の２つはマルチプラットフォームにする上で、
拡張する必要のある機能だと思っています。
ver0.2 HSP討論会
