自分はモジュール変数を一行に書かなければ辛いという意見を書きましたが
モジュール変数を委譲の配列として使用すれば
かなり定義できますな
これは毎回作成しなければならないのではなく
一回作成すれば使い回せるかんじです
あんまり直感的な操作ではないので
途中でよくわからなくなってくるのもありますが
あんまり大量のデータを格納してしますと
確認が大変なのでほどほどに
モジュール変数をどのように作成したり格納したりするかは
やってると微妙に納得いかない感が出てきて
リファクタリングのアジャイルですね
上手いこと実装出来なくて前に進まなくなってきますｗ
自分、モジュール変数を利用してて
３回くらい同じミスしたんですけど
例えば
モジュールAとモジュールBがあって
モジュールAをobj_Aとしてnewmodして
モジュールBをobj_Bとしてnewmodしたとします
で、モジュールAにはfuncAがあり
モジュールBにはfuncBがあるとします
で、コピペして、修正漏れがあり
funcBをobj_Aで呼び出してもエラーにならなかったです
funcA obj_A
funcB obj_A（コピペしたのにBと修正してない）
みたいな記述で
再現スクリプト必要っすかね？
自分は最近、Pythonの勉強中でございます
で、Pythonは特にメンバの記述をしなくても
メンバを代入したり、メンバの値を取得出来るっぽいです
で、HSPは#moduleの行にモジュール変数書いて
newmodで初期値入れて
setterとgetter書いてやっと使えますよね
確認用にdump命令みたいのかかなきゃいけないですし
なんかあんまりHSPの思想と合ってないような
めんどくさい操作しなくても代入したり取得したり確認出来たり
する方がHSPらしい気がしました
ちょっとHSP3って後方交換取っててすごいなあ
と思ったんです
でも、もうHSPTV!プログラムは動かないっぽいですね
HSPTV!プログラムは
小型の作品を対象としたランタイムなので
プログラム初心者にとってとっつきやすかったと思います
自分もコンテスト投稿はHSPTV!部門からです
そして、現在も行数の多いプログラムは完成しませんねｗ
なので
HSPTV!プログラムの後継のランタイムも
需要はあるのではないでしょうか
HSPTV!よりサイズの上限が大きかったり
名前をつけて保存ダイアログによる
SAVE/LOADもあるといいなあ
って言って、自分は、さすがにHSPTV!プログラム向けの
小型ゲームはネタ切れっぽかったり
自分も配列はドット派ですね
なんでオブジェクト機能の議論に配列の記法が出てくるのか
謎でしたが
オブジェクト指向の記法にドットが出てくるからかあ。なんて
配列をドットじゃなくするのは
配列にドットを使用しているとこを
エラー出してくるれるならいいかな？ってとこです
機械的に修正していってOKならいいのかな
でも大きいスクリプトとかデバッグするのが大変な人も
いるかもしれませんね
仮にHSP4で配列の記法としてドットを廃止するとして
でもHSP3はしばらく配布していそうですね
2.61も今でも配布してますし
Rubyと違って
HSPはゲームとかはexeで完結してるので
古いHSPでもexeにしちゃえば普通に実行出来る訳です
例えば今HSP3をVC2019でコンパイルしてしまえば
VC2019が10年くらい動くと
10年くらいは動作する訳です
10年以上経過して後方交換が取れないとか文句言っても
やりすぎな気もしますね
HSPTV!プログラムもHSP3の古いのなら動くのかな
とちょっと思いました
HSPTV!プログラムも最新のでは動かないですし
HSPLetも動かないですし
おちゃっこ様の3Dのも動かないっぽいですし
環境を全部切り捨てていないかと問えば否だったり
作者様が今後はHSP3のように一気には変更しないって
発言を読んだことはあるような
オブジェクト指向的に言えば
オブジェクトを第一引数にする使用は直感的ではなく
そっちもわかり易くして欲しいです
Pythonもメソッドの第一引数はselfという慣習もありますが
それともまた違うややこしさではありますが
なんかPythonの話がちょいちょい出て来ますが
Pythonも微妙にBASICの流れの言語なので
Pythonの機能とかも取り込んで欲しいっすね
関数/命令
関数で統一と言えばPythonも括弧記法の割合多くなったっぽいっすが
Rubyのように特に曖昧すぎなければ、どっちでも良い
って方がいいかもですね
命令によって関数記法、命令記法って定義されていますが
どっちでも良くていいものも多い気もします
自分がHSP初心者の頃、関数記法が導入されて
ちょっと異議を唱えたら怒られた過去がありますｗ