"Jon Harrop" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
and, on another note:
more recently I am faced with .NET, and once again considering the
possibility of doing my own implementation (otherwise, if I were to make use
of it, I would be left to the graces that the target system has either MS's
implementation or Mono available...).
but, the CLI continues to look like one of those things which would be
horridly painful to implement...
among the many other issues, there is this one: what to do about the
the metadata is stored in a form which would be relatively awkward to
process in-place without making a mess, and doesn't look particularly easy
to wrap with a general-purpose API (unless I sit around using bit-packed
integer keys to access it).
unpacking the metadata into a different form seems possible, but I am not
certain if this is the "ideal" option.
such an "unpacked" representation could be either a more convinient form of
the tabular format, or it could be unpacked directly into my main database
format (basically, a windows-registery style heirarchical database), either
as a direct structural transcription, or as a structural/semantic
I have a slight worry though, since if the databases are anywhere near as
large as the CLI's bit-packing layout seems to imply, then the
representation used by my main database could waste lots of space (being
based around linked-lists of nodes, key/value pairs, and interned strings).
I guess I always could make the partial optimization of using a hack for
compressing integers into strings:
allowing the "string" to point into the space-region associated with fixnums
(integers embedded into pointers), which would be assumed (in this context)
to be a string containing a number...
granted, this would not save "that" much though, if faced with "teh
crapload" of metadata nodes (several million of nodes?...).
I guess, little stops me from keeping a similar semantic structure to my
current DB, but switching to a more memory-compact (and maybe more
efficient) in-memory structure.
then again, it could turn out like what was the case with dumping textual
versions of my C-based databases: they were actually surprisingly compact
(generally 10s or 100s of kB), even in their verbose textual-dump form (if
they were 10s of MB, I would have more reason to worry...).
note, if I were to access .NET metadata like in my main DB, this would
likely involve all requests being encoded as strings which are interpreted
(totally ignoring here that .NET metadata is essentially a relational-table
style format, meaning that a path-based form is a questionable means of
and, maybe unpacking binary signatures (on reference) into my VM's textual
format, mostly because the binary signatures also seem like a much bigger
hassle to mess with (they are ambiguous apart from knowing the particular
assembly, whereas my framework generally passes around signature strings
freely and assumes that they are universally understandable...).