On Thu, 28 Jul 2005 15:46:14 +0300, Yuval Kogman
<[EMAIL PROTECTED]> wrote:
[...]
> I like your Pack object - that is the parsed template, but I'd also
> like to be able to generate these templates with a programmatic
> interface that isn't string concatenation...
>
> Is it just a simple data structure? Or do you have anything in mind?
I was thinking of having it compile down to as close to native code as
possable. But this may be premature optimization.
> Will we have more powerful nesting? I think this is in order
> nowadays.
Thinking about it the declarations are very similar to (un)pack
templates. So it may be possable to build them up from them. If my
compile template macro took a name and that name was then treated as a
new declaration we could do something like this.
Pack::compile byte {
@^_ :=: { pack => &chr, unpack => &ord }
}
Pack::compile null {
0x00 :=: byte
}
Indeed I can see the pack module as creating all of the builtins this
way. Further more this approach makes it concivable to have a set of
methods on the Pack object itself for example.
method Pack::declaration() returns Array of Pack
is doc("The declarations that this pack consists of in the
order of there application") {...}
method Pack::packer() returns Code is doc("The code that will
be run to pack using this pack object") {...}
method Pack::unpacker() returns Code is doc("The code that will
be run to unpack using this pack object") {...}
Mmmmmm if we have something that returns previousely defined
delarions and a constructor.
method Pack::declaration(::Class $class,Str $name) returns Pack is
doc("The Pack object which corrasponds to this declaration") {...}
method Pack::new(::Class $class,@declaration of Pack) returns
Pack is doc("Create a new Pack object composed of declarations") {...}
This would allow the best of both worlds. A template based system for
those of us who are creating our Pack's at compile time, and also an
OOish programmatic interface for thouse of us who need something more
convenient then string concatination.
> Actually, to be really wicked, I think that packing is just applying
> rules in reverse (this is tricky and indeterminate, since there are
> no alternatives or options in unpacking/packing), and unpacking is
> the opposite, with two exceptions:
>
> captures are converted by looking at the binary data and
> interpreting it, not just stuffing it in a string
>
> the syntax is different
The other diffrence is that unpacking makes use of pattens of fixed
length so it doesn't need to parse its input.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
