euremoのeramemo

Rubiera

TSTRやLOCALSのおかげで使いどころが減ったSTRを有効に使おう、という話。
もし「STRをバリバリ活用しているぜ」ということだと、今回はあんまり役に立たないかもしれない。maker時代は文字列変数は貴重だったので……。

さて、STR.csvにはSTR変数の初期値を書き込める。STRNAME.csvでSTR.csvの番号に名前をつけられる。ということはSTR.csvに数値を書いておいて、STRNAMEにその値の名前を書けば、定数のように使えるのではないか……という発想。STRは文字列変数なのでTOINTしなきゃいけないのだけど。

LOCAL = TOINT(STR:ENUM名)

みたいな。
で、ここまで考えたんだけど、文字列を添え字に使うときってアルファベットだけだったりするとまずいのでは？
文字列リテラルの展開の仕様がどうなっているのか分からないが、おそらくアルファベットだけだと変数とバッティングするから引用符を省略できないような気がする。

LOCAL = TOINT(STR:"ENUM")

こういうふうに書けば大丈夫なのかな。

＊追記＊

()を省略した場合、アイテム名と変数名が同一になる場合があります。その場合は変数が優先されます。

"()を省略"は多分()じゃなくて""のことだと思うのだが、変数名と被るときは引用符をつける、とすればいいかもしれない。今度試す。

そもそも添字にリテラルを直接渡さなければ問題にならないかもしれない。

@NUM, ARGS
#FUNCTION
LOCAL = TOINT(STR:ARGS)
RETURNF LOCAL

ARGSは文字列型だから、中身がなんであれ間違いなく文字列で参照できるだろう。試してないので分からないけれど。
そういえばeraSQNにNUMという関数があったのだが、中身はSELECTCASE文だった。まさしくこういう処理をすればいいような気がする。STR.csv使ってないようだったし。

http://w.livedoor.jp/eratoho/d/Emuera%A4ˤĤ%A4%A4Ƥ%CE%CA%E4­

LOCALは関数が終わっても値が保持され続ける、
つまりCでいうstatic（静的）な変数に近い挙動をする
だが、だからといってLOCALをstaticな変数として使うことは避けるべき
(中略)
つまり、前回設定した値に依存する処理は簡単にバグの原因になるのである
LOCALはあくまでもその1回の処理で閉じる使い方をするべきである

同じページにある「CALLFと擬似セッター」という項目には、

こうすると、関数@VALUEのLOCALにLOCAL@を使わずに参照可能になる。
一文字変数を使わずに複数の関数をまたいで配列を参照したい場合に有用ではある。

ということが書いてあり、まさしくLOCALのstatic利用の例になっている。別に、「使うことは避けるべき」って言ってるそばから例を提示することをあげつらうつもりではなくて、「結局使うのはいいの？　悪いの？　どっちなの？」という話。

http://sourceforge.jp/projects/emuera/wiki/excom#h...

疑似SETTERを作りたくてやった、今は反省している

使わないほうがいいといいつつも、前述のCALLFは擬似セッターの実現目的で実装されたということを考えると、「使ってもいいけど、分かった上で使ったほうがいいよ」ということだろうと解釈した。
つまり、LOCALをstaticな変数として使いたいなら、揮発性であることを念頭において使うべきだ、という話なんじゃないだろうか。

LOCALだけの話をしているけれど、LOCALSとSTRとSAVESTRを例にあげると理解の助けが得られると思う。

• STRは広域変数で、セーブされない。
• SAVESTRは広域変数で、セーブされる。
• LOCALSは局所変数で、セーブされない。

このとき、LOCALSがstaticに保持されることを利用すると、代入と参照用のユーザー関数を定義することによってSTRと同等のことができる。STRと同等のことをするためにLOCALSをstaticな変数として利用することは、べつにそれほど問題とは思わない。もしそうなら、STRの利用自体が問題になるし、全部SAVESTR使いましょうということになるからだ。
そんなわけはなくて、普通にSTRは有用だし、どんどん使ってかまわないだろうと思う。少なくとも元のeramakerでは、そうするよりほかなかったのだから。加えていうと、euremoは広域変数を使うくらいならstatic変数を使ったほうがいいと思っている。STRは多目的に利用されるけれど、ある関数に束縛されたstatic変数はある目的のために用意するわけだから、目的外の用途、つまりどこかで勝手に値が書き換えられるということも格段に減らせるだろう。

ここまで書いて、あんまりメリットについて書くと濫用する人も出てくるだろうから、そういう話はしたくないのかもしれない、などと思った。