Perl-Sensitive Sunglasses | |
PerlMonks |
Re: Embedding a mini-language for XML construction into Perlby shmem (Chancellor) |
on Nov 21, 2005 at 01:54 UTC ( [id://510336]=note: print w/replies, xml ) | Need Help?? |
Thanks for this nifty piece of code. I have been playing around and made your code into a module - certainly one which pollutes the callers namespace, since all entity and attribute functions have to be exported. I dont know how to keep the clear syntax and have it OO at the same time. Hmm... But apart from this, I suggest some changes in the rules of your game:
The first change improves legibility and avoids clashes with perl core functions (e.g tr/// vs. <tr>). The second is necessary per DTD.. Next would be completion of the entities and attributes array, and syntax checking - XML::DTDParser provides a simple way to do this.
Oh yes. About eval vs. symbol table - I don't see much difference here. Recompiled every time? no, each entity/attribute sub is created once via eval, and done. What shows up via perl -MO=Deparse is that every block as an argument to a subroutine prototyped as & gets its own code reference at each call of the sub if it occurs in a different context, but that's regardless of the use of eval. All blocks in calls to p in this snippet
will have the same CODE reference, but the next call to p will have it's own. After all, eval is not evil. The hairy monster is -- perl, the father of perl's eval. What eval is used for is up to the programmer, and if people use eval to compile insecure code - then I guess the surrounding code isn't any better. --shmemUpdate hmm, this doesn't seem to be a minimial-cost interface because of the reasons stated above - because each block gets its own reference which doesn't get destroyed or re-used. Wrap render_doc { }; into a sub and call it 10000 times and you'll end up with +192 MB of memory...Update The problem seems to be the anonymous $render_fn which doesn't get deallocated. Changing the block tosolves this issue. Sub in a sub? yes, render_fn has to see the my()-variables of render_via_xml_writer.
In Section
Meditations
|
|