[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