[#ga02364c]このバグが想定外かどうかで議論は分かれると思うので、まずは想定の範囲内かどうか判断してもらわないと。この問題自体が想定しているのは、:configのフォーマットが次のタイプです。|val3|val4|#contents*A.次の項目までが想定内ならバグではありません。[#t49e434d]:configへの書き込みは、Config#write()を使います。Config#write()はConfigTableクラスとそのサブクラスが持つtoString()が返す値を該当ページへ書き出す役割となっています。Config#read()で得られたConfigTableとそのサブクラスは、読み込み対象が表(段組)なので、ConfigTable_Sequentialでしょう。&color(blue){''Config#read()で作成したConfigTable_Sequential''};は、:configへの書き込みに適したフォーマット(要所に改行文字を含む)を返してくれますので、問題ありません。*B.次の項目までが想定内ならバグでしょう。[#tc8f022d]-:configへ、新しいヘッダ($title)と新しい表($values)を追加する。[#k277c22d]例えば、新しいヘッダ($title)をConfig#&amp;get_object($title)に渡して実行すると、新しくConfigTableオブジェクトを生成して返します。add(),put()に$titleを渡しても同様の動きを見せます。&amp;get_object()が生成するConfigTableは、&color(red){''"*"+$title''};なので、:configに書かれているデータは常にConfigTableを生成する条件に一致するものになります。[#dd1fdb21]そのまま、Config#write()をすると&color(red){''ConfigTable#toString()は$titleしか返してくれません''};。その為、新しい表($values)は無視されてしまい、:configへの書き込みは$titleのみとなります。ConfigTable_Directに振り分けて自インスタンスに保持します。対象はレベル1のConfigTable型なので、ConfigTableが返される条件と一致します。$ab->add_value(array('00000','11111'));例えば、Config#objsにConfigTable_Sequentialオブジェクトを追加して、値を追加したとします。*test_titleXX|00000|11111|Config#read()経由で作られたConfigTable_Sequentialは、$beforeに$title+"\n"を追加して保存します。$configtable_object)の形で使っている為次の様に書けば改行が追加されます。ConfigTable_Directはコンストラクタを持たないのでConfigTableのコンストラクタが処理をしてます。[#df19d23d]この部分の書き換えは、既存の'':configから読み込み''には影響しないと思います。読み込みでは、:configに存在しない$titleを指定する理由がありません。事故で想定していた$titleが見付からなかった場合等は、Configクラスの誤りではなく:configの誤りでしょう。&color(red){''指定された$titleは無い''};と返す方が最善だと思います。[#d8461d4c]ConfigTableとそのサブクラスを追加するメソッドを別途作成します。Configの中のオブジェクト配列への追加はこのメソッドに限定するべきです。引数の$config_tableはConfigTable型です。プリミティブな値を渡してメソッド内で判断するより、初めから型が決まったものを渡す方が後々面倒な事が起こらないでしょう。''$title+"\n"''が修正されなければ、期待しない文字が書き込まれる事になります。[#nabf3977]出力に関係する事なので、各toString()で対応すれば良いと思います。$beforeに格納する前に"\n"を除去しておくとか。他で"\n"を探さないのなら、この方が良さそうです。[#p5bdfb01]:configへ書き込まれるフォーマットによってConfig#read()が型を決めている為、親クラスであるConfigTableの#toString()が特定フォーマットを出力するのは好ましくありません。それぞれの子クラスで$titleを含めた形でoverrideされているの為、ConfigTable#toString()は不要だと思われます。一時データの受け皿として使うなら良さそうですが、フォーマットとデータ型が密接なので、最終的な受け皿としてConfigTableを使うべきじゃないと思います。pconfig.phpベースなら新規追加は想定されてませんね。