David_N_Bertoni wrote:
> As quick comment on the four things you mentioned:
>
> 1. This seems pretty straightforward, although I wonder
> about its affect on output transcoding. I guess one
> character at a time is possible, although it must be
> beastly slow.
The output viewer of ActiveState's debuggers only accepts UTF-8, and
that seems to work correctly, so I didn't really give it much more
thought. As to speed, it doesn't really matter for interactive
debugging. I could investigate changing flush to work at a bit higher
level but, in my patch, I just went for the easy implementation.
> 2. I'm pretty sure we already do this in the XPathExpression of
the
> XPath instance embedded in each ElemTemplate. Perhaps we just
need to
> expose that?
Where is it embedded? The only string-like thing in XPathExpresion (at
least in 1.1) is m_currentPattern. Is that the untokenized expression?
In any case, I think that storing the attributes for every element
type is potentially useful for a debugger.
> 3. I don't have a problem with this, although the variable stack
is
> really in need of an overhaul. I'm not sure how much that might
affect
> your work, but we can certainly try to design around it.
You guys do seem to change the variable stack a fair bit; I had to
almost completely rewrite this code during the 1.0 => 1.1 transition.
My biggest concern is that one day it becomes impossible to infer
callstack information from the variable stack. Other than that, I am
happy to adapt my code to work with any new variable stack.
> 4. This has been requested quite often. We might consider
> making this a derived class and allowing people to use it
> without doing a special build.
Using some sort of factory pattern? Or would there only be two
options? I would really like Xalan to use factories all over the place
(so I could change anything that I felt like) but I would imagine that
would have performance issues.
Cheers,
Brian
