[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