[prev in list] [next in list] [prev in thread] [next in thread] 

List:       velocity-dev
Subject:    Re: macro arguments may change implicitely - why notstorearguments in  local context ?
From:       "Claude Brisson" <claude () savoirweb ! com>
Date:       2002-03-28 16:21:44
[Download RAW message or body]

Ok, Geir, thanks a lot, your implementation works fine for my needs.

> We need to decide if it masks existing globals
> completely - you can't read the values of those already existing. I guess it
> should, however .... Dunno.  I can see that one either way.

Not sure the mask would be a so good idea : for the recursion case, for instance, the \
usage would not be as straightforward as it is now, as in :

#macro recurse($item)
    #local($item)
        ...
        #recurse($item.child)
        ...
    #end
#end

(there would be an extra reference, and an extra #set directive).

---

Btw, Geir, some mails ago in this tread, you wrote :

> > > Why not make context.localscope true?  What's the problem there?
> > - all needed global stuff must be passed as arguments to macros
> That shouldn't be true.

Did you mean that the actual behaviour should be changed, or that it should not be \
the actual behaviour ? 'cause it IS the actual behaviour, cf. VMContext.java get \
method,#223, where in fact 'get' should always behave the same way and ignore \
localcontextscope.

(hum... the comments reveal a cut&past from the 'put' method ;-) )

            if(localcontextscope)
            {
                /*
                 * if we have localcontextscope mode, then just
                 * put in the local context
                 */

                o =  localcontext.get( key );
            }
            else
            {
                /*
                 *  try the local context
                 */

                o = localcontext.get( key );

                if ( o == null)
                {
                    /*
                     * last chance
                     */

                    o = innerContext.get( key );
                }
            }


Thanx,

CloD




--
To unsubscribe, e-mail:   <mailto:velocity-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:velocity-dev-help@jakarta.apache.org>


[prev in list] [next in list] [prev in thread] [next in thread]