Daniel Rall wrote:
>
> "Geir Magnusson Jr." <[EMAIL PROTECTED]> writes:
>
> > Daniel Rall wrote:
> > > I must confess that I am much more used to the opposite behavior,
> > > where the symbolic reference $a first evaluates to the symbol
> > > $notincontext, then $notincontext renders literally because it's not
> > > in the context. However, I would be okay with either of these forms,
> > > so long as the behavior is clearly defined in the documentation.
> > >
> >
> > I'm (and I guess we all are, because that's the way it works...) used
> > to it too.
> >
> > However, I can't see how that is the desired behavior. The reason I say
> > this is because you are in a Velocimacro and you are using in the body
> > of the VM the 'arg variable'. Therefore, we know you aren't trying to
> > do something like
> >
> > $ale!
>
> I don't follow you.
>
> > The only useful bit about rendering '$notincontext' rather than '$a' is
> > that it helps you debug. How about we address this with a message
> > generated to the log (default off?) that says something like :
> >
> > Velocimacro arg $foo is null
> >
> > or something?
>
> What is the benefit of rendering $a literally instead of resolving it
> as what LISPers would refer to as a symbolic reference?
>
> > Then we get the debuggability as well as #if() w/o having to complicate
> > things...
>
> You say above that the current behavior is already in the style of a
> symbolic reference. In what ways does leaving things like this
> introduce complications?
The problem is that currently, to make VM args both work well and be
invisible, when they are null-valued in the context, I do return the
literal ('symbolic reference') instead of null, so the behavior would be
as you expect.
However, this breaks #if(), when something is null, because it tests the
value.
I noted in previous post that this was simply a decision to ensure
backwards compatibility. It can easily be switched so a null valued
reference in a VM returns null always, and therefore the literal /
symbolic reference will be that of the 'local' VM arg, not the passed in
arg.
I think this is acceptable, as it is in a VM - and the references in the
body that match the VM declaration 'variables' are clearly just that -
references. We render $<token> as $<token> when not in the context
everywhere else because it's not a reference - it's schmoo.
However, there may be a way around this...
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
