[antlr-interest] ST 4.0 planning

Terence Parr parrt at cs.usfca.edu
Mon Sep 8 16:49:40 PDT 2008


On Sep 8, 2008, at 1:48 PM, Gavin Lambert wrote:

> [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 --

That means that all of your objects will need to be rewritten,  
recompiled, and rebound into the app though right?

> 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.

Oh, you mean create an adaptor object that implements an intrface  
collected from every reference in a template?  How could you know  
until runtime what those types/methods are?

Hmm...i'm pretty sure nonreflective languages make ST hard to  
implement since it's untyped.  And I mean untyped (like assembly code)  
not dynamically typed like python.  I'd be overjoyed to be wrong  
though ;)

Ter


More information about the antlr-interest mailing list