FLAGS

MENU

NOTICE

2012年1月10日火曜日

シリアリゼーションの本質について考える (oka01-fytijttslsdnjimm)

筆者はプログラマである。この日記を書いた当時、個人に利用する目的で、Javaの仮想マシン上のオブジェクトをバイト列化し、復元する処理 serialization をする為のライブラリを開発しているところだった。この日記は、その時に考えついた事をメモしたものである。

Serialization(シリアリゼーション・直列化処理=ある実行環境に存在するデータを、バイト配列として出力し、後に復元する処理の事) に関する個人的なメモ。

データ型という存在のclassification を行う要素として、
  • value (値)
  • meaning (意味)
  • representation (表記)
  • function (機能)
の4つの要素を思いついた。 まだ他にもあるかも知れない。

Serialization という作業上の問題を解決するためには、値が保存され、値が復元されれば、用は足りる。 Serialization を実装するためには、値が保存され・値が復元される事が、必須最低条件である。 型に対してそれ以外の要素を classification する材料として持ち込むと、結果的に同じ処理に対して複数のルーチンが必要となり、必ず冗長化する。

ところが実際には、多くのデータ型は、あらゆる環境に存在する静的なクラスオブジェクトと結び付けられている事が多い。 クラスオブジェクトは、値以外にも意味・表記・機能などと結び付けられている場合が多い。 よって、どうしてもルーチンが冗長化する。

例えば、 配列とリストなどが良い例だ。 配列とリストは、実質上同じ値を持っている。だが、配列は固定長・リストは可変長となっており、異なる機能を持っている。 値の保存、値の復元というルーチンは同じであるにも関わらず、二つの別々なルーチンが必要となる。

更に考察を進めると、マップと配列というのも、値としては同じ物を持っている。 マップとは、値としてみると、Key-Value という二つの値を持つオブジェクトのリストである。だが、配列とマップは、値上同じであるとしても、機能上の違いがある。配列は往々にしてインデックスによるエントリへのアクセスする機能を実装するが、マップはKeyでエントリを検索しValueを出力する機能を実装する。 これも値の保存復元としては同じ処理であるにも関わらず、二つの別々なルーチンを要求する。

日付においては、更に複雑な違いを生み出す。 日付は往々にして、1900/1/1 0:00 +0 からのミリ秒として表すことで、大概は64bitの整数値として管理される。 つまり、日付の正体(値)は、整数値である。 しかし、データファイル上で、946688400000 などという数値がいきなり現れても意味が全く理解出来無い。それよりは、(Sat, 01 Jan 2000 08:00:00 GMT) という様な具体的なが現れてくれた方が、人間にとってはわかりやすい。 つまり (946688400000) と (Sat, 01 Jan 2000 08:00:00 GMT) の二つは、値は同じ物を表しているのだが、表記が異なると言い表すことも出来る。

こういう例も考えられる。 リンゴの個数を表すある数値 128という数を、例えば  (Thu, 01 Jan 1970 AD 07:00:00.128 ICT) と日付として表しても構わない。これは1970/1/1 0:00 GMT から 128ミリ秒後 の日付である。 確かにこのようにしても、データを保存し復元する事が出来る。 しかし、日付とリンゴの個数は、同じ整数値ではあっても「意味合い」が異なる為、人間が読む時に都合がよくない理由がある。

この「表記の違い」と「意味合いの違い」は、似ているが異なる違いだ。 リンゴの個数 128個を、例えば符号なし16進数で表すと、0x80 個と言い表す事が出来る。この0x80を 符号あり16進数で表すと、0x0080 である。この例の様に、意味合いは同じでも、複数の表記方法が存在する。


この様に、Serialization(シリアリゼーション・直列化処理) を実装するに当たって、必要なルーチンはただひとつ、値の保存と値の読み出しであるにも関わらず、シリアリゼーション処理を設計実装するに当たって、シリアリゼーションとは無関係な抽象的要素が多く紛れ込むことで、シリアリゼーション処理は、驚くほど複雑化する。



上で示した4つの要素
  • value (値)
  • meaning (意味)
  • representation (表記)
  • function (機能)

この要素に基づいて、起こりうる問題を予想すると、意味は同じなのに値が異なる場合や、 異なる値なのに表記が同じになる場合、機能は同じなのに、意味が異なる…等々、様々な冗長性が生まれるであろうことが、推測される。


これら4要素を次元とみなして、型を4次元のマトリックスで表す事は可能であるような気もする。 これらを正規化した形でシリアリゼーション処理を行うためのフレームワークを開発することは、果たして可能であろうか。 その際には、各次元は拡張可能・或いは固定で全てのパターンを表現できる様な設定である必要がある。 現時点では可能かどうか、判別がつかない。

著者オカアツシについて


小学生の頃からプログラミングが趣味。都内でジャズギタリストからプログラマに転身。プログラマをやめて、ラオス国境周辺で語学武者修行。12年に渡る辺境での放浪生活から生還し、都内でジャズギタリストとしてリベンジ中 ─── そういう僕が気付いた『言語と音楽』の不思議な関係についてご紹介します。

特技は、即興演奏・作曲家・エッセイスト・言語研究者・コンピュータープログラマ・話せる言語・ラオ語・タイ語(東北イサーン方言)・中国語・英語/使えるシステム/PostgreSQL 15 / React.js / Node.js 等々




おかあつ日記メニューバーをリセット


©2022 オカアツシ ALL RIGHT RESERVED