eraシリーズ改造/バリアント開発の覚え書き

2月4日の雑記


PRINT_SHOPITEMとか未実装だったらしいことに気付いたので実装。PRINT_ITEMはまだ手をつけてない。

で、今eratohoAを移植中なんだけど、eraTohoAってEmueraの関数使ってるので、これを移植しようと思ったらEmueraの関数もある程度組み込まなければいけない。変数はEmueraのも一部取り入れてるんだけど、こうなってくると見えてる部分はどんどん実装しちゃったほうが早いかもしれない。

配列変数の添字省略の件は$プレフィックスをつける方向で問題なさそう。trace_var試してみたけどやっぱりこれでいけそう。

ただ、こういうことされるとちょっと心配。

$A = 'hoge'
print A[0] #=> 'hoge'
A[0].upcase!
print A[0] #=> 'HOGE'
print $A   #=> 'HOGE'

一応動くことは動く。ただ、trace_varは破壊的な変更を伴う(!つきの)メソッドの動きを監視できないので、$AとA[0]が参照するオブジェクトが異なると、片方だけ変更されて、不整合が発生する。trace_varの中でcloneとか呼ばない限りは大丈夫なんだと思うけど。数値の場合はそもそも破壊的な変更ができないから問題ない。

まあ何にしてもこういう操作は非推奨ということにしておきたい。

あとグローバル変数COUNTを廃止して常にローカルなループのインデックスを参照するようにしたんだけれど、そのせいでcountが見つかりませんとエラー多発して困る。ユーザ関数の定義部に仮引数をもうけて、countを参照する関数を呼び出す側でcountを渡してやるように書き換えたりしないといけないようだ。まあそのほうがグローバル変数書き換えて死んだとかそういうことなくなって平和だと思うので……。

あと、RESULTSも廃止っていうのは書いたんだっけ。Rubyの場合、変数が型情報を持たないので、変数には何でも入れられるし。配列も要素毎に型が異なって構わない。RESULT相当の変数はResultというのを用意しているんだけど、こいつに文字列を代入すればいいだけのことなので、わざわざResultsを用意するのもなんだかなあ、と思っている。このへんどうなんでしょうね。INPUTSとかのこと考えるとあったほうがいいのかなーとか思ったりはするけれども。

eramakerとの互換性をあんまり意識しすぎると後で面倒だったりするし、かといってeramakerから離れすぎてもよくないし、悩ましい。

コメントをかく


「http://」を含む投稿は禁止されています。

利用規約をご確認のうえご記入下さい

リンク

漠々ト、獏
eramaker/eramaker2の開発元の公式サイト。

Emuera - emurator of eramaker
C#で書かれたeramakerのエミュレータ「Emuera」のプロジェクトページ。

eraシリーズを語るスレ まとめ
eraシリーズ全般のまとめ。バリアント情報、改造情報など。

eratoho まとめ
eramakerのバリアント「eratoho」のまとめ。

era板
eraシリーズについての掲示板。

サブページ

Rubiera
Bitbucket上のRubieraプロジェクトページ。Rubieraのソースコードのダウンロードはここで。

管理人/副管理人のみ編集できます