--- Brent Dax <[EMAIL PROTECTED]> wrote:
> Dan Sugalski:
> # At 12:10 AM -0800 1/23/03, Brent Dax wrote:
> # >Dan Sugalski:
> # ># Since it looks like it's time to extend the packfile
> # format and the #
> # >in-memory bytecode layout, this would be the time to start
> # discussing #
> # >metadata. What sorts of metadata do people think are useful
> # to have #
> # >in either the packfile (on disk) or in the bytecode (in memory).
> # >
> # >I do think that, whatever "native" (i.e. understood by
> # Parrot) metadata
> # >we support, we *must* allow for extensibility, both for
> # future native
> # >metadata and for third-party tools.
> #
> # "Must" is an awfully strong word, there. We don't really "must" do
> # anything, though I do realize the feature is useful, hence my
> # question.
>
> A strong word for a strong opinion. :^) Besides, I did qualify it
> with
> an "I do think", which is another way to say IMO.
>
> # > Moreover, this must not be
> # >implemented with a special type of metadata block, or by using
> # >sequentially-increasing numbers. (The first means that any
> # metadata we
> # >decide to add in the future will be slower than the metadata we
> add
> # >now; the second has problems with several third-party tools
> # picking the
> # >same
> # >number.)
> #
> # I'm afraid extensible metadata is going to live in its own chunk
> # unless someone can come up with a way to embed it without penalty.
> # (And I'm generally considering using separate chunks for the
> metadata
> # the engine does understand)
>
> Are you expecting to have chunk type determined by order? If so,
> what
> will you do if a future restructuring means you either don't need
> chunk
> type X or you need a new, highly incompatible version? Will you
> leave
> in an "empty" ghost chunk?
>
> I would suggest (roughly) the following format for a chunk:
>
> TYPE: One 32-bit number
> VERSION: One 32-bit number; suggested usage is as four eight-bit
> components
> SIZE: One 32-bit number of bytes (or maybe 64-bit)
> DATA: arbitrary length
>
> For C-heads, think of it like this:
>
> struct Chunk {
> opcode_t type;
> opcode_t version;
> opcode_t size;
> void data[];
> };
>
> Type IDs less than 256 would be reserved to Parrot (so we have plenty
> of
> room for future expansion); all third-party tools would use some sort
> of
> cryptographic checksum of the tool's name and the data structure's
> name,
> making sure (of course) that their type ID was greater than 255.
>
> If there's a directory of some sort, it should record the type ID and
> the offset to the beginning of the chunk. This should allow for a
> fairly quick lookup by type. If you think that there might be a
> demand
> for multiple instances of the same type of metadata, you may want to
> add
> a chunk ID of some sort.
Cool!
that means we can use opcodes to store the introspector data!
We need to have the meta data paired with the opcodes.
basically this means storing the source code in some ast form in the
meta-data for full reflection and introspection on the expression
level.
mike
=====
James Michael DuPont
http://introspector.sourceforge.net/
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
