I've been thinking about a few ideas for major changes to HTML::TreeBuilder
and HTML::Element. I'm not planning on implementing any of these any time
soon, but I thought I'd mention them and see what people think:
1) using WeakRefs, and making each Element object's link to its parent be a
weak reference. This would mean, however, that if you have a tree (holding
a reference to its $root), and then hold references to one or more
references under the root, but stop holding a reference to the root, then
the root goes away -- you end up with just a bunch of treelets. That is:
unless you held a reference to a node OR SOME ANCESTOR of it, it wouldn't
exist. I think that in current practice, tho, almost every time someone's
fiddling with a tree, they're holding a reference to its root for the whole
time.
The benefit of using weakrefs would be simply that programmers would never
have to remember to call $tree->delete (or $subtree->delete, for the fewer
of you out there who actually move tree content around). And I /think/ I
could make it so that that module (sans weakref functionality) would work
fine with versions of Perl too old to support WeakRef.
2) Having TreeBuilder's interface with Parser use callbacks instead of
subclassing. This would break everything that subclasses TreeBuilder --
but I don't know if anyone does that at all. (I don't recall the docs ever
saying that /can/ subclass TreeBuilder -- and doing so is not exactly
pleasant or productive.)
The benefit would be a speed increase -- presumably a moderate increase,
but not a dramatic one.
The cost is that everyone would /have/ to use the XS versions of
HTML::Parser. (Or, alternately, I could take the last pre-XS version,
spiff it up, and make it barely serviceable to the task of talking to
TreeBuilder; of course, modern HTML::Parser is very intelligent and
forgiving with bad code, and what I'm thinking of would be rather less
clever.)
Since neither of these ideas have exactly pressing motivations, and each
introduce some degree of compatibility problems, I'm not rushing to
implement either. In fact, I'm thinking of simply not bothering until Perl
6 -- that seems comfortably far off.
Neither of my above ideas would greatly affect the clarity of the code --
which I consider somewhat important. I don't expect anyone to have to
rewrite TreeBuilder from scratch for Perl since, well, it already exists
and works rather well. However, I think that TreeBuilder plus HTML::Parser
is one of the better open-source HTML parsers out there, and I do hope that
if ever anyone has to implement anything like it in some other language,
that they will simply look to TreeBuilder's and Parser's code and consider
"translating" some or all of it. And, if/when that happens, I should hope
that they find clarity in the code in TreeBuilder. (I can't speak for
Parser's clarity, as I don't read C all too well).
So, yes, if you need a robust HTML parser for, I dunno, Oberon V, I think
your time is better spent starting with the logic in HTML::Parser and
HTML::TreeBuilder than with what you'd find in, say, Lynx or the w3 mode
for Emacs. On the other hand, http://www.w3.org/People/Raggett/tidy/ might
be a good alternative. (And in a pinch, you might do well compiling Tidy,
shelling to it to convert HTML on hand into XML, and then all you have to
do is parse the nice clean XML it spits out.)
Your kilometrage may vary.
--
Sean M. Burke [EMAIL PROTECTED] http://www.spinn.net/~sburke/
