[stringtemplate-interest] StringTemplate type proxies

[Sam Harwell]

I worked to keep CL 7307 simple so you could reference it for this. I could
also provide a Java implementation if you'd like. Here's an overview:

1. The proxy factory interface can be registered in the same two places as
attribute renderers (on the template and/or on the group).
2. The proxy is requested in two places. These two locations cause the proxy
to be used for property lookups and rendering, before the attribute renderer
is used.
2a. At the beginning of ASTExpr.GetObjectProperty (after the check for
null).
2b. At the beginning of ASTExpr.Write(StringTemplate, Object,
StringTemplateWriter) (after the check for null).
3. The types for both attribute renderers and proxies are looked up in my
TypeRegistry<T> class, which takes the place of the hash table lookups that
were done previously. That class includes boiler code for implementing some
standard .NET interfaces, but the meat of the implementation lies in the
following methods. (Again, I'd be happy to implement this in Java if you'd
like.)
3a. Two fields, _backingStore and _cache (line 50-51), which for Java would
have types Map<Class, T> and Map<Class, Class>.
3b. The property "public T this[Type key]" (line 141-157), which for Java
would (I believe) be "public T getItem(Class key)" and "public T
setItem(Class key, T value)".
3c. The methods Add, ContainsKey, Remove, TryGetValue, and Clear (grouped
together in that order on lines 180-277).
3d. The HandleAlteration method (lines 366-371).

The _backingStore is a hash table of the exact types used for registering
(renderers or proxies). The _cache field is a Type->Type map used for
efficient base- and interface-class lookups. As a quick example, if a user
registers an attribute renderer myTypeRendererInstance for
java.lang.reflect.Type, then _backingStore contains
Type->myTypeRendererInstance. If the user then supplies a java.lang.Class
object as an attribute, then whenever the registry is queried for type
Class, it finds that there is no exact match so it stores Class->Type in
_cache as the "best weak match". If there is no match, then it stores
Class->null in _cache so it knows to proceed up the template hierarchy
without wasting time doing object model checks. All of this logic is
contained in TryGetValue. The key item for the other methods is making sure
the _cache is properly invalidated when any change is made to the
_backingStore.

-----Original Message-----
From: stringtemplate-interest-bounces at antlr.org
[mailto:stringtemplate-interest-bounces at antlr.org] On Behalf Of Terence Parr
Sent: Tuesday, December 14, 2010 1:17 PM
To: Rafael Chaves
Cc: stringtemplate-interest at antlr.org
Subject: Re: [stringtemplate-interest] StringTemplate type proxies

Very convincing argument, folks. thank you. 3rd party models.

Ok, so how do they interact with renderers?  I guess the renderer is done
*after* proxy stuff.

Proxy: RandomModelObject -> MyWrapperForRandomModelObject, adds getFoo() or
whatever.

Then, if getFoo() returns type Date, renderer applies to that.  I like it.  

I remember mentioning how to do this manually. just override setAttribute()
so that it traps RandomModelObject and wraps.  

Does this need to be formalized or can it simply be a FAQ entry?  it's a
switch on type, look up in hashtable thing only right?

Ter
_______________________________________________
stringtemplate-interest mailing list
stringtemplate-interest at antlr.org
http://www.antlr.org/mailman/listinfo/stringtemplate-interest