Someone wrote me privately about subclassing, and I think that what I wrote
back to them could be informative to the list. Here it is:
At 03:22 AM 2000-10-16 -0700, someone wrote to me privately:
>Are you making it so that it'll never be possible to subclass, or just
>that anyone who has, won't work but could rewrite the code?
...pretty much that it won't be subclassable at all.
Basically I'm thinking of making its interface to HTML::Parser be thru
callbacks instead of thru subclassing -- so anyone who subclassed
TreeBuilder with start(), end(), etc. handlers would find that they
suddenly weren't being called.
I figure that if anyone says "but I need to subclass it" and says how/why
they subclass, then I could either 1) point out a different way to achieve
the same effect, or 2) bother to figure out a trivial hack (like setting
the callbacks to $self->can('start'), etc., at constructor-time).
(Actually, people /could/ subclass the new TreeBuilder happily, as long as
they weren't overriding any of the (no longer there) handler-methods for
HTML::Parser, but then I can't quite imagine what the point of subclassing
would be. Possibly to just add some helpful methods, but there's other
ways to do that that might, for a particular person, be more appropriate.)
A few months back someone said they'd been subclassing TreeBuilder, but
that new features I'd added made that no longer necessary. But it's only
ever been that one person.
I figure if no-one on the libwww list says anything, then I would emit a
TreeBuilder version whose docs aver of impending unsubclassability, and
then the next version will warn() that subclassability will go away soon,
and then the version after will actually break it.
This might not even be necessary, but I definitely would like the option
open as I'm rearranging TreeBuilder's interface (but not really internal
logic).
--
Sean M. Burke [EMAIL PROTECTED] http://www.spinn.net/~sburke/
