皆様からご意見いただきたく、書き込みした次第です。リクエストしたい仕様変更とは以下のものです。・一つのeveファイルのみで有効な、変数とサブルーチンを扱えるようにして欲しい現在、変数はそのスコープ(有効範囲)から、以下の3つに分類されます。・サブルーチンローカル変数この中で、ローカル変数のスコープは、「ステージ内のみ」となっています。実は、外部のeveファイルをインクルードで取り込んだ場合、その外部ファイルもスコープに含まれます。この場合、一つの問題が生じます。インクルード指定を行った側のeveファイルと、呼び出された外部ファイルで使用されているローカル変数名が同じ場合(変数名の衝突)、変数の中身が破壊されてしまいます。「サブルーチンローカル変数を使用していないサブルーチン」を想像していただければ良いでしょう。これでは(少なくとも私は)、他人が制作したインクルードを安心して使うことができません。1「一つのeveファイル内のみで有効な変数」を作成・使用できれば(Privateは仮称です)、こうした危険は回避可能だと思います。Setコマンド等で自動作成される変数は今まで通りのスコープとすれば(仮にPublicと呼びます)既存のシナリオへの影響もないでしょう。「最初に定義されたサブルーチン」が、開発版では「最後に定義されたサブルーチン」が有効になるようです)。こちらもデフォルトのスコープをPublicとすれば、既存シナリオへの影響はないものと思います。皆様のご意見をお待ちしています。乱文長文失礼いたしました。02:39:23)拝見する限りでは支障の出る部分はなさそうです。あるとすれば同名サブルーチンの有効性に関する部分でしょうが、これとて現行安定版と開発版の両者では振る舞いが正反対であると言う点からすると、強硬に反対する理由にはなりえないでしょう。サブルーチン名称ラベルに対するスコープ定義をつけることで、安定版シナリオから開発版へ移植する場合に最低限の手間ですむようにできるかもしれないし、技術的に可能ならばこの仕様を推奨します。21:01:40)貴重なご意見有難うございます。>あるとすれば同名サブルーチンの有効性に関する部分でしょうが、>これとて現行安定版と開発版の両者では振る舞いが正反対であると言う点からすると、>強硬に反対する理由にはなりえないでしょう。私のリクエスト案としては、デフォルトのサブルーチンのスコープは、現状のままを想定しているので、開発版と安定版で振る舞いが異なるということはないと思います(というか、それでは流石にリクエストが躊躇われるし、反対する方も多いと思うので)。明示的にキーワード(例えばprivateのような)を指定しなければならない、という感じでしょうか。未指定の場合は、今まで通りのスコープが適用されます。反対意見がないようでしたら、機を見てリクエストを行おうかと思います。単純に考えれば「インクルードは引き継ぐ変数以外はLocalを徹底しましょう」で同様の効果が得られるのではないかと言う疑問と、「他人の作ったインクルードにPrivateがあるかどうかを心配しなければいけないのなら同じではないのか?」という疑問があります。22:23:06)反対意見を表明します。SRCはシナリオの記述形式として「イベント駆動型」の言語体系を採用しており、全ての制御は「イベント」を基本単位として行われます。そのイベントを駆動する過程で『イベントが記されているファイル』を判別する事は基本的にありません。元々のイベントファイルもインクルードされたファイルも、読み込まれた後では全く区別されていません。重要なのは「イベント」そのものであって、そのイベントがどこに記されていたのかを認識する必要は基本的にありません。これは実際のシナリオ制作の場合でも言える事です。作業用のインクルードを十数個のファイルに分けているシナリオもあれば、多数のイベントを全部1つのファイルにまとめている場合もあります。どちらでも全く差はないのですからそれも当然です。.........つまり何が言いたいのかと言えば、そういう現状の仕様から考えると『一つのeveファイル内のみで有効な変数』は明らかに『異物』だと言う事です。なくても特に問題なくシナリオは組めますし、あるからと言ってそれを素直に活用できるシナリオ作者もそう多くはないでしょう。全体の設計思想からズレがある機能を理解し、活用するのはそう簡単な事ではありません。『変数名・ラベルの重複』というのはプログラミングのミスとしてはかなり初歩的かつ基本的なものであり、各自で対処するより他に対策の取りようもないのが現実です。仮にそういうミスが頻発しているというのなら(現状でDLできるシナリオの中ではあまり見ない種類のミスですが)、SRCの仕様よりもまずシナリオ作者の技量そのものの向上を目指すべきではないかと。いうか.........ぶっちゃけた話、『一つのeveファイル内のみで有効な変数』などという高度な機能を活用できるシナリオ作者が『変数名やラベルの重複』などという基本的なミスに対処できないわけがないのですから、本末転倒ではないかと。仕様変更に問題があるかどうかという以前に『利点がない無意味な提案』であると判断せざるを得ません。費用対効果の観点から考えるに、仕様変更に必要な時間と手間に見合うだけの利益が得られるとは到底思えません。よって、リクエストには反対です。23:51:18)賛成します。プログラミングにおいて「変数・関数名の重複」は非常に大きな問題ですし、これの導入によってインクルードの導入における危険性を大きく減らすことができるためです。反対意見に対する意見を。分裂夢さんに対する意見ですが、>作業用のインクルードを十数個のファイルに分けているシナリオもあれば、>多数のイベントを全部1つのファイルにまとめている場合もあります。>どちらでも全く差はないのですからそれも当然です。この場合、プログラミング的に優れているのは明らかに前者です。機能別にファイルを分割するのは大変重要なことです。このシナリオで使った機能を他のシナリオでも使いたいと考えた場合、優れた記述をしてあれば、ファイルをコピー&ペーストして数ヶ所の修正を加えるだけで済みます。仕様を変更する際なども、変更するべき場所が一目で分かるようになります。何を言いたいかというと、確かにシナリオを製作する上でファイルを意識する必然性はありませんが、意識すれば(製作者側が)より便利になるということです。そもそも、「インクルード」があるということから、このようなファイル別に処理を分割するという設計思想があるということを垣間見れるのではないでしょうか。>ぶっちゃけた話、『一つのeveファイル内のみで有効な変数』などという>高度な機能を活用できるシナリオ作者が『変数名やラベルの重複』などという>基本的なミスに対処できないわけがないのですから、本末転倒ではないかと。その「基本的なミス」の対処として、この機能は大変有効なのです。シナリオ書きの腕、というかプログラミングの腕が上がるに従って、ソースコードの再利用や、他人のインクルードの導入などを行うようになります。複雑なインクルードの場合、大量の変数・ラベルを使用することがあります。量が増えてきた場合、高い確率でミスが発生します。プログラミングにおいては、ソースコードの再利用の際にこのような手間がかかることは決して好ましいことではありません。ひろ2号さんへ>「インクルードは引き継ぐ変数以外はLocalを徹底しましょう」>で同様の効果が得られるのではないかこの場合問題になるのは、その「引き継ぐ変数」です。(つまりLocalでない変数)それと同じ名前の変数がメインにあった場合、変数の内容が破壊されてしまいます。02:51:56)貴重なご意見をいただき有難うございます。>分裂夢さん>そのイベントを駆動する過程で『イベントが記されているファイル』を判別する事は基本的にありません。元々のイベントファイルもインクルードされたファイルも、読み込まれた後では全く区別されていません。>重要なのは「イベント」そのものであって、そのイベントがどこに記されていたのかを認識する必要は>基本的にありません。これらは、プログラムの実行レベルでの話だと思います。大きくなり過ぎたソースファイルの分割というのは、ごく普通に行われています。一言で言うと「開発効率の向上」のためです。SRCでインクルード機能がサポートされているのも、同様の理由だと思いますが、ファイル分割の前提としてのファイルスコープが存在しないのは、そうした機能を使う上で安全性に欠けるのではないか、というのが今回の提案に至った動機です。>SRCはシナリオの記述形式として「イベント駆動型」の言語体系を採用しており、全ての制御は>「イベント」を基本単位として行われます。「モジュールレベル変数の使用」は機能としてサポートされています。Basicからの引用です。>また、『変数名・ラベルの重複』というのはプログラミングのミスとしてはかなり初歩的かつ>基本的なものであり......(中略)......基本的なミスに対処できないわけがないのですから、>本末転倒ではないかと。した基本的な事柄こそ、開発者レベルで解決すべき問題ではなく、言語レベルで解決されるべき問題なのではないでしょうか。「サブルーチン内ローカル」というスコープが存在していることを、一度考えてみてください。分裂夢さんがが挙げたこれらの理由は、「Localコマンドが必要ない理由」(事実使用していないシナリオ作者の方もいるようですが)にそのまま当てはまってしまいます。理解していただけると思うのですが。>ひろ2号さんサブルーチンに関しては特に触れられていないようなので、変数に関してだけレスさせていただきます。>単純に考えれば「インクルードは引き継ぐ変数以外はLocalを徹底しましょう」で同様の効果が>得られるのではないかと言う疑問たしかに、プログラミングでは一般に、「変数はより小さいスコープにする」というのが原則とされています。それに従えば、ローカル変数よりは、サブローチンローカル変数が優先して使用されるべきです。場合によってはたとえば、(同一ファイル内の)複数のサブルーチンで共通して扱うようなデータは、データの個数が多い、サイズが大きいなどの理由で、サブルーチンローカル変数(または配列)にして引数で値をやりとりするよりは、ローカル変数にして複数のサブルーチンからアクセス可能にした方が良い場合もあります。「SRW風ステータス表示インクルード」などがその一例でしょうか。サブルーチンローカル変数は、サブルーチン終了後は値が破棄されるので、何らかの理由で終了後も値を保持しなくてはならない場合も、ローカル変数を使用せざるを得ません。変数の「情報隠蔽」がもたらすメリットは、必ずしも「他人が制作したインクルード」だけに適用されるわけではありません。これはLocalコマンドと同様です。05:26:55)どうも、XAKです。ファイル内でのみ有効な変数の実装に賛成します。内部を確認して変数が被ってないかチェックする必要が出てきます。通常の1話1EVE形式のシナリオ作成ではあまり役に立たなさそうな機能ですが、大量のインクルードファイルを使用するシナリオではとても有用に感じます。既存のシナリオ等に影響を与える可能性は、まず有り得ないためリクエストする価値は充分にあると考えます。20:34:04)ついでに亀レスもお詫びします。19:23:17)ある程度意見も出尽くしたようなので、以後反対意見がないようなら賛成多数ということで、近日中に以下のリクエストを行いたいと思います。併せてリクエストしたいと思います。最後に、貴重なご意見をお寄せくださった皆様に、心よりお礼申し上げます。