Paulo Gaspar wrote:
>
> Geir,
>
> Took sometime to get back at this (an interesting movie on TV).
Me too! I went to see "Crouching Tiger, Hidden Dragon." Great movie.
Sorry to run off like that.
> Ok, there is a single point for introspection call which is from:
> ASTIdentifier.doIntrospection( Class data )
We do it in a few other places as well. Yes, it might be good to bring
those together into one place, but this is a very expensive aspect of
Velocity's operation, so we need to be careful.
> Now, having:
> public interface IntrospectionBuilder
> { public AbstractExecutor doIntrospection( String identifier, Class data )
> throws Exception;
> }
>
> and an extra field for the Parser class like:
> public final IntrospectionBuilder introBuilder;
Why the Parser class? The parser has nothing to do with this - there is
nothing static about this : a parsed template must be able to be used by
multiple contexts at the same time. By this I mean nothing at parse
time dictates the introspection information. My servlet using a parsed
template can use an object with a method getFoo(), and your servlet
using the same parsed template can use an object with a hashtable with
"Foo" as a key, and if the template has $ob.Foo, we both are happy.
This feature is one of the most powerful and beautiful, I think... :)
> one could replace the introspection call (in ASTIdentifier.execute()):
> executor = doIntrospection( c );
> by
> parser.introBuilder.doIntrospection( identifier, c );
Sure. Still wondering about the parser bit though.
> Profits:
> The possibility of having plugable introspection, even per Parser.
I see the benefit of pluggable introspection just for the modularity
alone, although I wouldn't be thrilled about including in the vel
distribution anything but a 'standard' introspection module, just for
sanity's sake, and to avoid encouraging people from doing things like
accessing things they shouldn't. 'public' and 'private' are there for a
reason :) Of course, that would be up for a general vote, I guess.
> Costs:
> - An extra member, and its initialization, for the Parser class. Since
> a pool of such objects is used, this is a very low cost.
> - A couple of extra references and an extra parameter to create the
> introspection. This is not such high cost either.
Yes, after thinking about it, there prollie wouldn't be much cost to it.
> Well, actually, maybe this costs less than keeping and initializing that
> "method" field (in the ASTIdentifier class) that is not being used any
> more.
> =;o)
Yes, that's just a leftover. Not sure how that relates here.
>
> What do you think about this?
>
> Paulo
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Geir
> > Magnusson Jr.
> >
> > Before we consider that, does the above solve your problems?
> > Pluggable discovery sounds slow, and Vel isn't going anywhere big
> > unless we get to JSP-like performance.
> >
> > geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
