[stringtemplate-interest] StringTemplate type proxies

[Terence Parr]

On Dec 14, 2010, at 12:22 PM, Rafael Chaves wrote:

> Yeah, I'd rather register an instance instead of passing in a class
> and let ST instantiate it. That would address your concern about
> efficiency, but it is just better design IMO.
> 
> On how to determine whether the wrapper should be activated, I'd hope
> it would be based on an "instanceOf" match instead of an exact class
> match (which is a grip I have with AttributeRenderer).

interesting. seems render could be  instanceOf but an adaptor should be per type, shouldn't it?  Perhaps instanceof then prioritized by order you register, right? oh, that's what you say below. :)
T

> I don't
> necessarily know the classes of the objects I am dealing with
> (implementation classes are often not exposed to clients of an API,
> but I will know some public class or interface), or may be interested
> in a hierarchy of classes. True, that leaves some room for multiple
> wrappers being interested in the same object, but you can decide based
> on order of registration (first or last to match wins) - for a single
> template, it is reasonable to assume there is only on party involved.
> 
> Cheers,
> 
> Rafael
> 
> On Tue, Dec 14, 2010 at 12:06 PM, Terence Parr <parrt at cs.usfca.edu> wrote:
>> Ah! You are so correct! It only works on the values you pass through setAttribute. Ok, so the proposition is to simply add
>> 
>> registerProxy(ModelType, MyProxyType)
>> 
>> and have ST created new MyProxyType object with
>> 
>> new MyProxyType(aModelTypeObjectAttribute)
>> 
>> for each reference to a ModelType object? Won't that get inefficient? perhaps it should be like renderer and we  create a single object to wrap any object?
>> 
>> $a.foo$ would invoke method MyProxyType.getFoo(a), right?
>> 
>> Am  I going in the right direction?
>> 
>> Ter
>> 
>> On Dec 14, 2010, at 11:28 AM, Rafael Chaves wrote:
>> 
>>> Yup, renderers translate from whatever values to String. The decorator
>>> (not a proxy, as it augments the shape of the target object) allows
>>> obtaining the values.
>>> 
>>> This should apply at any level in the model graph, not only top level
>>> attributes. Does setAttribute handle that?
>>> 
>>> For instance: Package has Classes with have Attributes. I set only one
>>> attribute on the top-level template, to be the root package object,
>>> and then navigate the graph with several templates (one for packages,
>>> one for classes, and another for attributes).
>>> 
>>> Will overriding setAttribute allow me to intercept how any arbitrarily
>>> deep object is handled?
>>> 
>>> Cheers,
>>> 
>>> Rafael
>>> 
>>> On Tue, Dec 14, 2010 at 11:16 AM, Terence Parr <parrt at cs.usfca.edu> wrote:
>>>> 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
>> 
>> 
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest