[antlr-interest] ST 4.0 planning

[Loring Craymer]

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.

--Loring


----- Original Message ----
> From: Terence Parr <parrt at cs.usfca.edu>
> To: Loring Craymer <lgcraymer at yahoo.com>
> Cc: stringtemplate-interest <stringtemplate-interest at antlr.org>; antlr Interest <antlr-interest at antlr.org>
> Sent: Monday, September 8, 2008 11:52:26 AM
> Subject: Re: [antlr-interest] ST 4.0 planning
> 
> Actually,I pass in lots of aggregate objects like User and FAQEntry  
> and Grammar. We need field access I'm afraid.
> 
> Ter
> On Sep 8, 2008, at 11:45 AM, Loring Craymer wrote:
> 
> > Ter--
> >
> > I think that the reflection requirement is unnecessary and  
> > undesireable.  An attribute is usually one of:  1.) a String, 2.) a  
> > StringTemplate, or 3.) Boolean, and you could probably avoid  
> > Booleans as well with a bit of judicious design (single-valued  
> > "true" or "false" strings, for example).  On rare occasion, it may  
> > make sense to support an esoteric data type, but that can be handled  
> > via wrapper:  the wrapper, after all, only needs to know how to do  
> > "toString()", and it is trivial to implement subclass wrappers for  
> > each esoteric type.  For that matter, you could support a generic  
> > Java wrapper that used reflection, but subclass a base wrapper class  
> > in languages that do not support reflection.