cuemol2memo

CueMol2開発メモ

2007/5/20

  • jsbr/ObjWrapper
    エラー処理をするようにした.(throwErrorを呼び出す)
  • JS bridgeのthrowErrorの実装
    単にJS_ReportError()を呼び出せばよいようだ.
  • qlib/TestClass.hpp JSから呼び出すテスト / qlib/testclass.js
    objectが関係ないmethod: OK
    objectを渡すmethod: OK
    objectを返すmethod: OK

2008/3/8

XML関連

System中では、Objectとそれに対応するXMLNodeObjが存在。 XMLNodeObjはDOM Treeの簡略化版みたいなもの。

  1. デシリアライズ時、 XML parserがXMLNodeObjを作る。XMLNodeObjからObjectが作られる。
  1. Object編集時は、XMLNodeObjに直ちには反映しない。XMLNodeObjは、どちらかというと、ファイル中のXML文書を反映した状態を保っている。
  1. シリアライズ時、Objectの内容をXMLNodeObjに反映。 更新されたXMLNodeObjがXML streamに書き出される。(ObjToXML更新)

上記3パターンのみをサポートする。 XML文書から、既にあるオブジェクトをアップデート(XMLToObj更新)はサポートしない。 Serialize時には、上記ではアップデートをサポートするように書いているが、まずは非アップデート型(毎回全生成)で実装すればよいのでは。ただし、そうすると、手書きのXMLのコメントやフォーマットなどがすべて失われるという問題点がある。

Nodeタイプには、2種類存在。

  • Tableタイプ:あるインタフェイスを持つオブジェクトを(多数)保持。保持されているオブジェクトに対応するタグが一定ではなく、ランタイムに決まる。オブジェクトはunique ID (数値)でindexされている、かつ、リストのように順序を持つ。
  • Propタイプ:プロパティのみを持つ場合。 プロパティの型はコンパイル時に決まっている。

XMLNodeObjとObjectの対応付け

非アップデート型実装では、不要(毎回破棄/生成するだけだから)

アップデート型実装では、

  • XML→Obj では、XMLから対応するobjectを知る必要がある。
    対応するObjectがある(可能性のある)XMLNodeObjはUIDを持っている。 UIDから、objectを検索できる(getXMLPeer() method)。既に削除されているかどうかもUIDから判断可能。
    今の実装では、ObjToXML更新をgetXMLPeer()を使っておこなている。すべてのXMLNodeに対して、UIDを得てから対応するObjがあるか検査し、ある場合はUpdate、ない場合はCreationを行っている。
    上述の分析から、この実装は不要ではないのか?
  • Obj→XML では、Objectから対応するNodeObjを知る必要がある。
    Serializableなobjectは、XMLObjNodeへのSmartPtrを保持している。 対応するXMLNodeがない場合は、このポインタはヌルになっている。
    上述のような理由により、現実装では使用されていない。

2008/3/8

Object階層の構成

ObjTable
uid→ObjectのHashテーブル.uidはobjectが出来た順にグローバルに付けられるので,実質的にはリストになる.
基本的にSceneを構成するcollection objectはこれを用いる.Sceneなどでは,object nameはユーザに見えるヒントでしかないので,同一名前が存在することを許す.
派生クラスの実装で,名前でソートしたり,同一名を排除したり,別の基準でobjectの順序・存在を制御出来るようにする.
ObjTableはinterfaceで,insert(データの追加),get(uidからobjectの取得), getAllUIDs(全UIDの集合を取得)の3つからなる.
それ以外
全てPropertyは保持出来るようにする.ObjTableもPropertyをもてたほうが良い.

XMLによるPropertyの表現

Attributeによる表現
XMLのattrによってあらわすため,文字列になる.
数値・文字列の場合は自明.
色,shadingなど,さらに構造を持つ記述は独自のMarkupが必要になる.(色以外は対応する必要が無いだろう)
HTMLのように,JSで記述することも必要.(ただ,HTMLのonXXXプロパティでは,JSの評価値がattrとして設定されるのではなく,文字列をJSとしてcompileしたcodeletが設定される仕様である.この違いをどうするか?)
文字列への変換はLScrConvCapインタフェイス,void fromString(string value)と, string toString() constでサポートする.個別実装はこの下に隠蔽.
ただし,同じ値に対して複数表記がある場合(0.0と0.00等),文字列としての表現がfrom/toを減ることで変化してしまうと言う問題が起り,Update型実装では何らかの対処が必要.
Children tagによる表現
そのelementの子element(tag)に記述する.
数値・文字列の場合は冗長になる.
色,shadingなどの構造もXMLによりMarkupできる.

Children tagによる記述の方が(冗長になる面もあるが)汎用性が高い.

LScriptableはLScrConvCapを含んでいる(全てのscriptableなclassは実装しなければならない.)

問題:結局XMLNodeObjは2種類しかないので,XMLNodeFactoryは不要なのではないか. getXMLElemName()のみあればNodeObjは作成できるのではないか.

2008/4/12

DOM-likeな一時オブジェクトツリーを作るのなら、全バージョンのserialization機構と類似の方式でも良いのではないか?

Matrix4Dの実装

LRegExprの実装 PCREを使用。 jsで使用する場合、パターンの\をいちいちエスケープしなければならない、という問題がある。

mcwrapgen3のデバッグ

QIF型が決まると、流通している型(SetterだとSRC, GetterだとDEST)がPTRかSPかは決まる。当たり前だが、流通型はポインタしかありえない。

JS・XPCOMともに、SetterとArgument処理のコードがおかしかったので、以下のよう修正。

Setterの場合、

  • DEST=値/const referenceの場合、
    • SRC=<PTR>→*でアクセス
    • SRC=<SP>→*でアクセス
  • DEST=PTRの場合、
    • SRC=<PTR>→p->copy()でアクセス、必要に応じてコピーが作られる
    • SRC=<SP>→p->copy()でアクセス、(必要に応じて)SPではなく、本体のコピーが作られる
  • DEST=SPの場合、
    • SRC=<PTR>→単純コピー
    • SRC=<SP>→単純コピー

上記のように実装。 Argument処理も基本的に同様。

Variant型(LVariant)の参照セマンティクス

通常は、LVariantは一時的な値の保管に使われるだけ。 生存期間はローカル変数あるいは関数への引数レベル。(メンバーとして参照されるようなことは無い)

一方で、LVariantにptrを格納して返すmethodは、必ずcopy()したptrを格納して返す。 しかし、これはLVariantがそのptrの指すobjectを所有していることを意味するのではない。呼び出した側(のコード)が所有していると考える。

そのため、LVariantから取り出したptrを格納するに当たってcopy()を呼び出す必要はないし、LVariantのデストラクタはclientのdestruct()を呼び出さない。

正しい使用方法:呼び出した側が、使用後に明示的にcleanupPersistentReference()を呼び出す、あるいは、ほかの所有(persistent)的なobjectにcopy()することなく渡してしまう。


Last-modified: Sat, 12 Apr 2008 23:58:30 JST (6027d)