Re: macro arguments may change implicitely - why notstorearguments in local context ?

["Geir Magnusson Jr." <ge...@optonline.net>]

On 3/27/02 12:12 PM, "Christoph Reck" <Ch...@dlr.de> wrote:

> Thanks Geir. It will sure be useful; but for the moment I'm stuck with
> debugging/enhancing/extending a swing application - no chance now to
> setup and test the new #local directive.

It may be useful, and it needs more work :)
> 
> Looking over the code I saw that it takes the current values of a given
> list of references and restores them later. It does not handle the case
> where listed local references are not available globally - null's are
> then restored?!

That¹s a valid issue - I think that if $foo isn't a valid reference before
the call, then it shouldn't be after.

> 
> So it acts a bit different than the #foreach loop variable. The way its
> implemented in Local.java might be ok - more to this below.
> 
> 
> I thought that the contract of the #local directive should be allowing
> to create context variables without affecting the callers (of macros
> and parsed documents). It sould also enable one to have some local
> declared variables dissapear after the #end.

Yes - that it should be.  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.
 
> 
> If the #set( $foo = null ) handling is implemented as proposed in another
> thread (to remove the reference from the context) then the current Local.java
> will probably work:
> * references without dots will be saved and restoring them will
> remove local ones that did not exists before.

Because the real user context is wrapped, anything that didn't exist before
shouldn't be added - the outer context is removed, leaving the inner.  You
can't add 'null' anyway to the context, so this shouldn't be a problem.  If
it is (i.e. If the internals aren't forcing the 'no null' semantics) then
it's easy to check and not add it.

> * references with dots will restore values within references (it might
> call the setter with a null value when no proper get was available - but
> whoever does #local($foo.bar $woogie.bang)...#end should know what he
> is doing).

This actually is very problematic, as $foo.bar can imply $foo.setBar(value),
which has every chance of modifying state of the reference.  This isn't good
- there is no way to really protect that.  Copying a reference to the outer
protecting context obviously won't work, and doing a clone of it is just too
scary for my tastes.

We could just restrict the use of #local() to simple references rather than
the identifier/property idiom...

> This latter one sounds a bit like magic, but it is orthogonal to simple
> references so it should be OK.

So maybe we restrict to that...
 
> some more inline...
> "Geir Magnusson Jr." wrote:
>> 
>> On 3/27/02 8:42 AM, "Christoph Reck" <Ch...@dlr.de> wrote:
>> 
>>> Claude Brisson wrote:
>>>> 
>>>> Thank you for your responses, Christopher & Geir.
>>>> [snip]
>>>> Chirstopher's #local directive proposal looks quite right to me, and I
>>>> volunteers to write it.
>>>> But (supposing my code is ok), will it be incorporated as a new
>>>> functionnality ? A patch has a quite short lifetime...
>>>> Time for what, now, votes, or validation, or something ?
>>>> 
>>>> Thanx,
>>>> 
>>>> CloD
>>> 
>>> If you looked the ForeachDirective source and understood how parameters
>>> are passed to directives, then you can go ahead and implement it.
>>> 
>>> Geir, would a LocalDirective make it into the core or into the contribution
>>> sections?
>>> 
>> 
>> I did one yesterday in a boring session here at J1, and just put it into
>> whiteboard/geir
>> 
>> Give it a look.
>> 
>> I really don't think we should jump ahead and make this core - we can
>> support it in a contrib section, and if people really, really find it
>> useful, we should talk about adding it, but I don't think it's really a core
>> function...  Just my 0.02
> 
> I believe this is a candidate for core since it greatly enhances the
> usability/reliability of a (well written) generic macro library.

People believe all sorts of things :)

That is a valid point though.
 
>> 
>>> I you do not get flamed on cons about implementing a local directive, and
>>> Geir states he can put it into CVS, then you can read it as a "go ahead".
>> 
>> With pluggable directives, anyone can implement anything.  If there are good
>> contribs, we keep them.  But we don't have to add them to the core if they
>> are not obvious or in widespread use.
> 
> OK
> 
>> Having 'local variables' is something
>> that makes a lot of sense to us programmers, but I would bet means very
>> little to designers.
> 
> The 'local variables' feature is addressing programmers of #macro libraries
> and reusable template fragments (#parsed).

Don't forget that #macros() are designed for designers - "...they are just
bits of VTL so designers can take advantage of the concept of reuse...."

But yes, it is useful.
 
> Others don't have use them or even know about it.
> 
> In a previous project with another template language I used included/parsed
> templates to create complex form fields to handle data structures (e.g.
> geographical coverage, time ranges, etc.)
> 
> Also note that a #macro with a #local inside makes recursions a
> straightforward thing to follow. No magic on how to ensure the recursion
> will work.

Yep
 
>> 
>> I personally have a use for this, but I don't think many people do.
> 
> Dito.
> 
>> 
>> Geir

-- 
Geir Magnusson Jr.                       geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>