[antlr-interest] ST 4.0 planning
Gavin Lambert
antlr at mirality.co.nz
Mon Sep 8 13:48:32 PDT 2008
[I would send this to stringtemplate-interest as well, but I'm not
subscribed so it won't let me.]
At 07:46 9/09/2008, Loring Craymer wrote:
>I agree that you take advantage of field access at times, but
that
>can be replaced with table lookups in most cases, and a smart
>wrapper can be substituted for a table if dynamic evaluation is
>absolutely necessary. You don't need reflection; you just take
>advantage of it in the current Java implementation.
Indeed. Almost anything you can do with reflection you can do by
implementing a common interface -- and the little you can't do
with that can be done with one of those interface methods being a
"fetch me this data by name" type method (and companion
setter). The only holdout requiring some kind of factory method
instead, which could simply be implemented via a different common
interface.
It wouldn't be hard to make a dual-mode system where it'll first
try using a common interface and failing that fall back on
reflection (if available). That way people using Java or C# can
choose whether they want to implement the interfaces or not (doing
it would be slightly more work for the user but should improve
performance significantly, since reflection is fecking slow), and
C/C++ users would be required to implement the interfaces.
(Admittedly I know almost nothing about how StringTemplate works
internally, but still...)
More information about the antlr-interest
mailing list