Without any analysis of this proposal I would like to point out a few of the weaknesses in todays solutions.

1. Efficency. We desperately need something better than array_sscanf(f->read(n), "%"+n+"c")[0]; to read n byte integers from file objects. I think the best solution is a generalized "stream" wrapper kind of thing. class RichStreamAPI(Stdio.File|API.Stream|string x)

(This is in line with the wishlist item to unify the stream APIs in Pike, like charset codecs, gz/bzip2/etc compression, crypto functions etc)

2. Conditional struct items. I am fairly pleased with how my ADT.Struct worked out in my SWF-decoder, but when items depend on other items to determine their size or existence, I doesn't feel well supported. E.g. this is an example of the RECT primitive in Flash that consists of 5 bits size followed by the box coordinates using that size as number of bits.

class RECT { inherit BitStruct; Item nbits = UB(5); Item xmin = SB(0); Item xmax = SB(0); Item ymin = SB(0); Item ymax = SB(0);

void set_size(Item item, object file) { item->size = this->nbits; }

void create() { xmin->add_decoder_cb(set_size); xmax->add_decoder_cb(set_size); ymin->add_decoder_cb(set_size); ymax->add_decoder_cb(set_size); ::create(); } }

I should mention that the ability to used a finished struct class as an item in a new struct class has proven to be very helpful.

3. Alignment. Again, using my Flash decoder as past experience, you need to be able to define rules for how items fit together. In Flash files, whenever a byte-item follows a sub-byte item, there is a byte alignment occuring. It is possible to work around this by having knowledge of what data is consumed on a sub-byte level in the input object (Stdio.File based class in this case), but something that would benefit from some redesigning)