ＳＲＣ意見交換掲示板Mk2 [One Topic All View / リクエストします / Page: 0]

ＳＲＣ意見交換掲示板Mk2
(現在過去ログ12 を表示中)

[ 最新記事及び返信フォームをトピックトップへ ]

■1358 / inTopicNo.1)

　意見募集：変数とサブルーチンの仕様変更

□投稿者/ ANSI -(2002/12/17(Tue) 15:59:19)

既存のシナリオには（恐らく）影響を与えない仕様変更なのですが、
「変数」「サブルーチン」というプログラムの根幹に関わる事柄なので、
皆様からご意見いただきたく、書き込みした次第です。
リクエストしたい仕様変更とは以下のものです。

・一つのeveファイルのみで有効な、変数とサブルーチンを扱えるようにして欲しい

現在、変数はそのスコープ（有効範囲）から、以下の３つに分類されます。

・グローバル変数
・ローカル変数
・サブルーチンローカル変数

この中で、ローカル変数のスコープは、「ステージ内のみ」となっています。
一見すると、「そのeveファイル内でのみ有効」と考えられがちなのですが、
実は、外部のeveファイルをインクルードで取り込んだ場合、その外部ファイルも
スコープに含まれます。この場合、一つの問題が生じます。

インクルード指定を行った側のeveファイルと、呼び出された外部ファイルで使用されている
ローカル変数名が同じ場合（変数名の衝突）、変数の中身が破壊されてしまいます。
「サブルーチンローカル変数を使用していないサブルーチン」を想像していただければ良いでしょう。
これでは（少なくとも私は）、他人が制作したインクルードを安心して使うことができません。

以下のような感じで、

Private var
Set var 1

「一つのeveファイル内のみで有効な変数」を作成・使用できれば（Privateは仮称です）、
こうした危険は回避可能だと思います。また、Setコマンド等で自動作成される変数は
今まで通りのスコープとすれば（仮にPublicと呼びます）既存のシナリオへの影響もないでしょう。

サブルーチンについても同様に、

Public func1:

（中略）

Return

Private func2:

（中略）

Return

というように、スコープ別に定義が可能ならば、一つのeveファイル内でしか使用しない、
下請けのローカルなサブルーチンも、安心して使えるのではないでしょうか（自分が確認した限り、
現状では、サブルーチン名が重複した場合、インクルードされたファイルも含めて、安定版では、
「最初に定義されたサブルーチン」が、開発版では「最後に定義されたサブルーチン」が有効になるようです）。
また、こちらもデフォルトのスコープをPublicとすれば、既存シナリオへの影響はないものと思います。

以上です。皆様のご意見をお待ちしています。
乱文長文失礼いたしました。

引用返信/返信削除キー/

■1367 / inTopicNo.2)

　Re[1]: 意見募集：変数とサブルーチンの仕様変更

▲▼■

□投稿者/ くらばーと -(2002/12/21(Sat) 02:39:23)

拝見する限りでは支障の出る部分はなさそうです。あるとすれば同名サブルーチンの有効性に関する部分でしょうが、これとて現行安定版と開発版の両者では振る舞いが正反対であると言う点からすると、強硬に反対する理由にはなりえないでしょう。
むしろサブルーチン名称ラベルに対するスコープ定義をつけることで、安定版シナリオから開発版へ移植する場合に最低限の手間ですむようにできるかもしれないし、技術的に可能ならばこの仕様を推奨します。

（賛成１票）

引用返信/返信削除キー/

■1371 / inTopicNo.3)

　Re[2]: 意見募集：変数とサブルーチンの仕様変更

▲▼■

□投稿者/ ANSI -(2002/12/21(Sat) 21:01:40)

貴重なご意見有難うございます。

>あるとすれば同名サブルーチンの有効性に関する部分でしょうが、
>これとて現行安定版と開発版の両者では振る舞いが正反対であると言う点からすると、
>強硬に反対する理由にはなりえないでしょう。
説明不足のため、誤解を与えてしまったようで申し訳ないのですが、
私のリクエスト案としては、デフォルトのサブルーチンのスコープは、現状のままを
想定しているので、開発版と安定版で振る舞いが異なるということはないと思います
（というか、それでは流石にリクエストが躊躇われるし、反対する方も多いと思うので）。

端的に言うと、「ファイル内のみに有効」という新しいスコープを使用する場合は、
明示的にキーワード（例えばprivateのような）を指定しなければならない、という感じでしょうか。
未指定の場合は、今まで通りのスコープが適用されます。

特に反対意見がないようでしたら、機を見てリクエストを行おうかと思います。

引用返信/返信削除キー/

■1372 / inTopicNo.4)

　Localでは駄目なのでしょうか？

▲▼■

□投稿者/ ひろ２号 -(2002/12/21(Sat) 21:22:34)

　ご提案の趣旨は、「Localを宣言していないサブルーチンを使ったときに、
メインとサブに同名の変数があると、変数が破壊されるおそれがあるので、
１つのイベントファイル内でのみ有効な変数Private（仮称）をリクエストしたい」
でよろしいのでしょうか？もしそうだとしたら、現在のLocalコマンドとどう異なる
のか今ひとつ判らないので、解説いただけないでしょうか？
　単純に考えれば「インクルードは引き継ぐ変数以外はLocalを徹底しましょう」
で同様の効果が得られるのではないかと言う疑問と、「他人の作ったインクルードにPrivateがあるかどうかを心配しなければいけないのなら同じではないのか？」という疑問があります。「Localの徹底」では得られない効果があるのでなければ、
私のようなソフトウェアの知識が少ない人間にとってはLocalだけの方がわかり
やすいのですがどうでしょうか？

（解釈に誤解が無ければ反対１、誤解があるなら無効票）

引用返信/返信削除キー/

■1373 / inTopicNo.5)

　Re[1]: 意見募集：変数とサブルーチンの仕様変更

▲▼■

□投稿者/ 分裂夢 -(2002/12/21(Sat) 22:23:06)

　反対意見を表明します。
　
　ＳＲＣはシナリオの記述形式として「イベント駆動型」の言語体系を採用しており、全ての制御は「イベント」を基本単位として行われます。そして、そのイベントを駆動する過程で『イベントが記されているファイル』を判別する事は基本的にありません。
　元々のイベントファイルもインクルードされたファイルも、読み込まれた後では全く区別されていません。重要なのは「イベント」そのものであって、そのイベントがどこに記されていたのかを認識する必要は基本的にありません。
　これは実際のシナリオ制作の場合でも言える事です。作業用のインクルードを十数個のファイルに分けているシナリオもあれば、多数のイベントを全部１つのファイルにまとめている場合もあります。どちらでも全く差はないのですからそれも当然です。
　………つまり何が言いたいのかと言えば、そういう現状の仕様から考えると『一つのeveファイル内のみで有効な変数』は明らかに『異物』だと言う事です。なくても特に問題なくシナリオは組めますし、あるからと言ってそれを素直に活用できるシナリオ作者もそう多くはないでしょう。全体の設計思想からズレがある機能を理解し、活用するのはそう簡単な事ではありません。
　
　また、『変数名・ラベルの重複』というのはプログラミングのミスとしてはかなり初歩的かつ基本的なものであり、各自で対処するより他に対策の取りようもないのが現実です。
　仮にそういうミスが頻発しているというのなら（現状でＤＬできるシナリオの中ではあまり見ない種類のミスですが）、ＳＲＣの仕様よりもまずシナリオ作者の技量そのものの向上を目指すべきではないかと。
　というか………ぶっちゃけた話、『一つのeveファイル内のみで有効な変数』などという高度な機能を活用できるシナリオ作者が『変数名やラベルの重複』などという基本的なミスに対処できないわけがないのですから、本末転倒ではないかと。
　
　では、結論を。
　仕様変更に問題があるかどうかという以前に『利点がない無意味な提案』であると判断せざるを得ません。費用対効果の観点から考えるに、仕様変更に必要な時間と手間に見合うだけの利益が得られるとは到底思えません。
　よって、リクエストには反対です。

引用返信/返信削除キー/

■1374 / inTopicNo.6)

　賛成です

▲▼■

□投稿者/ ナス -(2002/12/21(Sat) 23:51:18)

賛成します。プログラミングにおいて「変数・関数名の重複」は
非常に大きな問題ですし、これの導入によってインクルードの導入における
危険性を大きく減らすことができるためです。

と、賛成意見についてはほぼANSIさんの仰るとおりなので、
反対意見に対する意見を。

まず分裂夢さんに対する意見ですが、
>作業用のインクルードを十数個のファイルに分けているシナリオもあれば、
>多数のイベントを全部１つのファイルにまとめている場合もあります。
>どちらでも全く差はないのですからそれも当然です。
この場合、プログラミング的に優れているのは明らかに前者です。
「ソースコードの再利用性や保守性」という観点で見ると、
機能別にファイルを分割するのは大変重要なことです。もしこのシナリオで使った
機能を他のシナリオでも使いたいと考えた場合、優れた記述をしてあれば、
ファイルをコピー＆ペーストして数ヶ所の修正を加えるだけで済みます。
また、仕様を変更する際なども、変更するべき場所が一目で分かるようになります。

つまり何を言いたいかというと、確かにシナリオを製作する上でファイルを
意識する必然性はありませんが、意識すれば(製作者側が)より便利になるということです。
そもそも、「インクルード」があるということから、このようなファイル別に処理を
分割するという設計思想があるということを垣間見れるのではないでしょうか。

>ぶっちゃけた話、『一つのeveファイル内のみで有効な変数』などという
>高度な機能を活用できるシナリオ作者が『変数名やラベルの重複』などという
>基本的なミスに対処できないわけがないのですから、本末転倒ではないかと。
その「基本的なミス」の対処として、この機能は大変有効なのです。
シナリオ書きの腕、というかプログラミングの腕が上がるに従って、
ソースコードの再利用や、他人のインクルードの導入などを行うようになります。
しかし、特に複雑なインクルードの場合、大量の変数・ラベルを使用することがあります。
それらをいちいち照合するのは大変な手間だと思いませんか？
確かに、この機能がなくても手動で行える作業ですが、
量が増えてきた場合、高い確率でミスが発生します。
そしてプログラミングにおいては、ソースコードの再利用の際に
このような手間がかかることは決して好ましいことではありません。

ひろ２号さんへ
>「インクルードは引き継ぐ変数以外はLocalを徹底しましょう」
>で同様の効果が得られるのではないか
この場合問題になるのは、その「引き継ぐ変数」です。(つまりLocalでない変数)
それと同じ名前の変数がメインにあった場合、変数の内容が破壊されてしまいます。

>「他人の作ったインクルードにPrivateがあるかどうかを
>心配しなければいけないのなら同じではないのか？」
Privateはそのインクルードの中でのみ有効なものなので、
インクルードを利用する側としては何も気にする必要はありません。

以上、長文・乱文失礼いたしました。

解決済み!

引用返信/返信削除キー/

■1375 / inTopicNo.7)

　反対意見・疑問点へのマルチレス

▲▼■

□投稿者/ ANSI -(2002/12/22(Sun) 02:51:56)

貴重なご意見をいただき有難うございます。
ナスさんのレスと被ってしまう部分もあるのですが、
一応題名の通りです。

>分裂夢さん

>そのイベントを駆動する過程で『イベントが記されているファイル』を判別する事は基本的にありません。
>　元々のイベントファイルもインクルードされたファイルも、読み込まれた後では全く区別されていません。
>重要なのは「イベント」そのものであって、そのイベントがどこに記されていたのかを認識する必要は
>基本的にありません。
これらは、プログラムの実行レベルでの話だと思います。
開発過程、即ちソースレベルでは、言語がイベントドリブンであれなんであれ、
大きくなり過ぎたソースファイルの分割というのは、ごく普通に行われています。
「プログラムの保守性の向上」や「プログラムの再利用」など、理由は様々にありますが、
一言で言うと「開発効率の向上」のためです。

SRCでインクルード機能がサポートされているのも、同様の理由だと思いますが、
ファイル分割の前提としてのファイルスコープが存在しないのは、そうした機能を使う上で
安全性に欠けるのではないか、というのが今回の提案に至った動機です。

>ＳＲＣはシナリオの記述形式として「イベント駆動型」の言語体系を採用しており、全ての制御は
>「イベント」を基本単位として行われます。
そもそも、SRCの開発言語であるVisual Basicも通常、イベント駆動型の言語に
分類されますが、そのVisual Basicでも、ファイル分割が行われることを念頭においた、
「モジュールレベル変数の使用」は機能としてサポートされています。先に用いた仮称、
「Private」と「Public」はこのVisual Basicからの引用です。

>また、『変数名・ラベルの重複』というのはプログラミングのミスとしてはかなり初歩的かつ
>基本的なものであり……（中略）……基本的なミスに対処できないわけがないのですから、
>本末転倒ではないかと。
むしろこうした基本的な事柄こそ、開発者レベルで解決すべき問題ではなく、言語レベルで
解決されるべき問題なのではないでしょうか。SRCにおいて、Localコマンドによってもたらされる、
「サブルーチン内ローカル」というスコープが存在していることを、一度考えてみてください。
分裂夢さんがが挙げたこれらの理由は、「Localコマンドが必要ない理由」（事実使用していない
シナリオ作者の方もいるようですが）にそのまま当てはまってしまいます。少なくとも、
Localコマンドのメリットを実感している方には、ファイルスコープが存在しないことの危険性についても、
理解していただけると思うのですが。

>ひろ２号さん

サブルーチンに関しては特に触れられていないようなので、変数に関してだけレスさせていただきます。

>単純に考えれば「インクルードは引き継ぐ変数以外はLocalを徹底しましょう」で同様の効果が
>得られるのではないかと言う疑問
たしかに、プログラミングでは一般に、「変数はより小さいスコープにする」というのが
原則とされています。それに従えば、ローカル変数よりは、サブローチンローカル変数が
優先して使用されるべきです。

ただ、場合によってはたとえば、（同一ファイル内の）複数のサブルーチンで共通して扱うようなデータは、
データの個数が多い、サイズが大きいなどの理由で、サブルーチンローカル変数（または配列）にして引数で
値をやりとりするよりは、ローカル変数にして複数のサブルーチンからアクセス可能にした方が
良い場合もあります。「SRW風ステータス表示インクルード」などがその一例でしょうか。

また、サブルーチンローカル変数は、サブルーチン終了後は値が破棄されるので、何らかの理由で
終了後も値を保持しなくてはならない場合も、ローカル変数を使用せざるを得ません。

>「他人の作ったインクルードにPrivateがあるかどうかを心配しなければいけないのなら同じではないのか？」
変数の「情報隠蔽」がもたらすメリットは、必ずしも「他人が制作したインクルード」だけに適用される
わけではありません。自作も然りです。これはLocalコマンドと同様です。

引用返信/返信削除キー/

■1376 / inTopicNo.8)

　賛成です

▲▼■

□投稿者/ XAK -(2002/12/22(Sun) 05:26:55)

どうも、XAKです。

ファイル内でのみ有効な変数の実装に賛成します。

ファイル内で共有したい変数は現状どうしても全スコープの変数に
するしかなく、このため他人のインクルードファイルを使用する場合、
内部を確認して変数が被ってないかチェックする必要が出てきます。

通常の1話１EVE形式のシナリオ作成ではあまり役に立たなさそうな
機能ですが、大量のインクルードファイルを使用するシナリオでは
とても有用に感じます。

また既存のシナリオ等に影響を与える可能性は、まず有り得ないため
リクエストする価値は充分にあると考えます。

以上です。

引用返信/返信削除キー/

■1377 / inTopicNo.9)

　頼むからこんなとこで＜ｐｒｅ＞はやめれ～

▲▼■

□投稿者/ くらばーと -(2002/12/22(Sun) 09:39:19)

本ツリーの内容から外れるお願いですが、レイアウト上に特に必要がないのに図表モードで書き込むのはやめて～
１０８０ｘ１０２４でもはみ出してるよ～（泣）

引用返信/返信削除キー/

■1378 / inTopicNo.10)

　賛成です．

▲▼■

□投稿者/ 安藤大地 -(2002/12/22(Sun) 23:43:13)

賛成します．

インクルード作者，シナリオ作者双方にとても有効であると思います．
既存のシナリオへの影響を考えると，これはベストではないかと．

私の感覚から言えば，特別な宣言をしない変数は全てLocalであるべきだと考えてしまうのですが(笑)，
既に既存の仕組みで既に多くのシナリオやインクルードが作成されている事を考えると，
今回の意見がベストではないかと感じました．

引用返信/返信削除キー/

■1380 / inTopicNo.11)

　ごめんなさい

▲▼■

□投稿者/ ひろ２号 -(2002/12/25(Wed) 20:34:04)

ついでに亀レスもお詫びします。

引用返信/返信削除キー/

■1412 / inTopicNo.12)

　リクエストします

▲▼■

□投稿者/ ANSI -(2003/01/17(Fri) 19:23:17)

ある程度意見も出尽くしたようなので、以後反対意見がないようなら
賛成多数ということで、近日中に以下のリクエストを行いたいと思います。

・同一ファイル内のみで有効な変数の実装
・同一ファイル内のみで有効なサブルーチンの実装

また、先に述べた通り、既存のシナリオに影響がないように、デフォルトでは
今まで通りのスコープという形でリクエストするつもりですが、ソースの可読性を
考慮して、今まで通りのスコープの変数やサブルーチンを、明示的に使用できる機能も、
併せてリクエストしたいと思います。

最後に、貴重なご意見をお寄せくださった皆様に、心よりお礼申し上げます。

引用返信/返信削除キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

HOME HELP 新規作成新着記事トピック表示検索新着情報過去ログ

- Child Tree -
- Antispam Version -