「115. データ・ストラクチャーでの重複定義 QUALIFIED」でも説明したとおり
DS (= Data Structure) で QUALIFIED を定義しておくと
同じフィールド名を別々の異なる DSで使用していても
明確に異なるフィールドとしてOS は識別してくれる。
というのは DS は構造体の性格を持っているというか、
まさしく C言語等に言うところの構造体であるので
同じ構造体を異なる RPGソースの中で使用するケースが多くなる。
このときDSソースをコピーしたりインクルードすると
元あるRPGソースの同じ名前のフィールドと重なってしまう可能性がある。
QUALIFIED というのは直訳すると「資格を与える」とか「意味のある」とかいうような意味であるが
それなりの意味がある DS と言ったところだろうか。
C言語であると同じ名前の変数を再び重ねて定義しようとすると
重複定義としてコンパイラーのエラーとなってしまう。
ところがご存知のように RPG の場合は重複の名前の定義であってもタイプと長さ、小数が同じであれば
コンパイル・エラーとはならず通ってしまう場合がある。
それはそれで良い場合もあるのだが、意味のあるDSを
いろいろなプログラムの中で多用したのであれば明確な区別が必要となる。
その意味で QUALIFIED による DSの記述はこれからの時代では常識として一般化されて
使用される傾向にある、といっても間違いない。
【例】
D APIERR DS QUALIFIED D GETBYT 1 4B 0 INZ(160) D AVLBYT 5 8B 0 INZ(0) D APIID 9 15 D APIDTA 17 160
… QULIFIED を定義しておくと例えば GETBYT という名前のフィールドが他で
定義されていてもコンパイルの重複定義のエラーとは見なされない。
GETBYT は DSの名前を冠にして
EVAL APIERR.GETBYT = 160
というように表現することが必要である。
もうひとつ QUALIFIED とする利点は構造体の配列を作れる、という点である。
これまで配列というと文字や数字などのひとつの属性の配列でしかなかったのだが
構造体という意味の持つ配列を作ることができる利点がある。
例えばフィールド構造体を考えてみよう。
フィールド構造体は属性として
- フィールドの名前
- 属性
- 長さ
- 小数
という 4つの要素からなりたっているものとする。
このフィールドの配列を作るとき、従来の手法では
- フィールド名の配列
- 属性の配列
- 長さの配列
- 小数の配列
という 4つの配列を作成する必要があったが QUALIFIED を定義しておけば
フィールド構造体の配列をひとつ作るだけでよい。
ひとつだけの配列であっても各要素は
- FDR(N).FLDNAM
- FDR(N).ATTR
- FDR(N).LEN
- FDR(N).DEC
というように個別に区別して扱うことができる。
これはまさしく QUALIFIED によって定義された DS はあたかも
C言語の構造体 ( typedef ) のようであるし、 VC++ のクラス ( Class ) のようでもあるのだ。
QUALIFIED というキー・ワードは一見、何でもないようであるが
確実に RPG という開発言語を進化させている。
QUALIFIED は初めから IBM の RPG 開発者たちが必要であるとして追加したものではなく
他の開発言語を知っている開発者たちが RPG を眺めてみて
本質の修正が必要な部分を修正したのだと思える。
最近、RPG は確実にしかも大幅に進化しており見ていくともはや昔の時代の RPG ではない。
IBM i OS Ver7 のサンプル・ソースを見れば RPG III や ILE-RPG の固定フォーマットまでの
知識の人が見ればもはや別の言語であり理解不可能になっているかも知れない。
IBM のサンプル・ソースもあまりにも進みすぎているように思えるのだが
それではサンプル・ソースを理解できないので、次回以降はこのあたりを少しずつ紹介して
最新の RPGソースを紹介していくことにしよう。