[Yhc] Regarding Yhc bytecode versioning

[Robert Dockins]

On Oct 30, 2006, at 6:54 AM, Samuel Bronson wrote:

> On 10/29/06, Robert Dockins <Robdockins at fastmail.fm> wrote:
>
>> It may also be a good time to think about a ways to future-proof the
>> file format so that future additions can be made without breaking
>> compatibility.  Right now the format is quite fragile.  Perhaps we
>> could take inspiration from the Java classfile format.  The basic
>> idea is that there are named blocks of data with a minimal header
>> which gives the name of the block and the size of the data payload.
>> The name of the block defines the meaning of the data.  Eg, the
>> 'CODE' block contains bytecode instructions, etc.  If any block is
>> encountered with an unrecognized name, it is ignored.  That way, one
>> can have optional blocks, or one can add blocks without breaking
>> compatibility.  One can also have optional information (like
>> debugging symbols) and things of that nature.
>
> Do they all have four character names in the java classfile format?

Um... I'd have to look it up (its been awhile since I worked with  
this), but I'm pretty sure it just references the string table and  
that the names can be an arbitrary string.  At any rate, that's  
certainly how I would do it.  I'd probably suggest that something  
like URIs be used for block names if this format is eventually  
adopted.  URIs give a nice wide namespace and portions of it can be  
parceled out pretty easily.


> Like in PNG or IFF or RIFF(the basis of the horrid AVI container
> format, among other things)?


Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG