On Tue, 10 Jul 2001, Morten Jorgensen wrote:
> Erwin,
>
> Thanks a million for all your effort! You are the first 'external'
> contributor to the XSLTC code, so congratualtions. I'll buy you a
> pint if you come over to Dublin for the Apache conference later
> this year...
Hi,
Nice to hear that some of the submission was useful. I've been seeing a
lot of XSLTC bug reports on the list; hopefully they weren't caused by
those changes.
I see the Dublin conference has been cancelled. That's a shame, I had
hoped to see some faces 'behind' the names.
> o) I've already made some changes to our handling of <xsl:if>
> and <xsl:when> to check if they wrap unsupported external
> functions. I still added your fix to FunctionCall and the
> BasisLibrary classes, with the minor modification of emitting
> warning messages when calls to unsupported functions are
> compiled into the translet.
That's nice. I've only seen such use of extension functions in Norman
Walsh'es stylesheets, but they are important enough to take into account,
IMHO.
> o) Some of the illegal method names had already been changed
> and now contain underscores instead of dollar-signs.
Okay. Have you thought about real escaping? I think that according to the
spec, you can have different named templates (or variable names, etc) that
only differ by a hyphen, dot or underscore character (i.e. "tmpl_1",
"tmpl.1" and "tmpl-1") and that is not possible in XSLTC if you use
single-character escaping.
The dollar sign is nice since the Java language spec advices that it is
only used for automatically generated names, and it is not valid in an
XSL variable or template name.
You could use the sequence $d for a dot and $h for a hyphen.
> o) I've made some minor changes to the way you compiled
> IFNE skip
> GOTO_W far_away
> instead of
> IFEQ far_away
>
> but most of your changes are exactly as they were in the diffs.
> Some of these changes are very impressive, especially in the
> Mode class, where the code can be very hard to understand.
Thanks.
It is still problematic, though. If the method is quite small, the
extra space used by IFNE/GOTO_W instead of IFEQ is significant, and in
large methods I didn't fix all cases.
I believe that an extra level of abstraction is be needed that allows the
bytecode to be split up in several methods after it has been generated.
That would involve significant changes in the way the BCEL library is
used.
> o) Your changes to Include and Import were implemented as they
> were in the difs
>
> o) Some of your changes to the error/warning handling in the Parser
> class is changed a lot. I don't want to include stack traces in
> the error/warning messages.
True. That's only useful for debugging the XSLTC code.
Regards,
Erwin Bolwidt
