Jose :
> > From: Christoph Reck [mailto:[EMAIL PROTECTED]]
> >
> >
> > > > -0, I can very well imagine VMs updating the parent
> > context (more below).
> > > > Whereas the tools and defaults set up as a base context should be
> > > read-only.
> > >
> > > Are we talking about the same thing?
> >
> > don't know? Jose gave the example:
> > > > > #macro(m1 $p1)
> > > > > #local($a)
> > > > > $set( $a = $p1 )
> > > > > $set( $appVar = $a + $a )
> > > > > #end
> >
> Just to elaborate on my example to avoid confusion. The macro is trying to
> modify the context "appVar" entry with the value of its parameter doubled.
> am just trying to do it so the macro repeats the macro parameter twice.
> he implementation tries to avoid re-evaluating the expression by using
> local variable which will disapear at the end of the macro.
The only time I would think you would care if $a is something that alters
state when it is invoked, right? But this can be solved by something like
;
#set( $appVar = 2 * $p1 )
but I realize that wasn' t the point :)
Another solution is to adopt a formality to define throwaway references,
such ash $foo_ or something (little tail to tell you it's throwaway...) Or,
we make it so that all new references declared in VMs are local - they don't
affect the global context. I kinda like this, but worry that it places too
much of a restriction. More on this later.
> > >[snip]
> > > > Singleton pattern with a private constructor:
> >
> > Jose's example is not serialization safe, equals() will not work:
> > > > > public static final Object NULL = new Object();
>
> Equality works fine! Object defines equality to be true only when the two
> references are the same (same Object). So NULL.equals(NULL) is true.
>
> s there a need for the values in the Context to be serializable?
> I have not seen such a requirement before. In any case, you would need
more
> that just defining a class for this to work. You need to implement the
> serialization function so that when the value is reloaded you put in the
> context the correct constant since the constant NULL is per ClassLoader.
Yes, we should make it serializable, so the context could be serialized for
servlet sessions, for example.
[snip]
> > > The local/end thing will be fixed soon w/o new directives
> > > (I hope:) There
> > > are a couple of related issues I want to knock off in one
> > fell swoop.
> >
> > I'm eager to find out how you will do it. See my note on this in the
> > "Context chaining examples" post.
> > I guess it could be what Jose once posted (within the VM rendering):
> > 1. save the arguments that match ones in the current context,
> > 2. evaluate the passes parameters and put them into context
> > (this would also avoid multiple evaluation of passed parameters)
> > 3. render the macro
> > 4. restore the saved arguments
> >
> I think this behavior as the common way to dealt with macros was rejected.
No, it was rejected because we lost major functionality, namely the call by
name (or whatever), which I think is important to preserve so context tools
can be passed into a VM, and they are invoked for every instance, not just
the output of one instance.... A solution is coming...
> That is why I introduced #local directive in my example. As used in the
> example, we could implement this directive without usage of new Context
> implementations. All you need to do is for the directive when rendering to
> do the following:
> 1. Look in the context for a variable of the same name as the one used
> in #local and save it on the execution stack.
> 2. Set the variable in the Context to NULL (the constant).
> 3. Render the block
> 4. On exit, set the variable in the context to the original value
> (or remove it from the Context if it was not defined before).
> This is a very simple implementation, that should work just fine. Allows
for
> modification of Context since Chaining is not used, and it only relies on
> the NULL constant.
I have the fix for the context / recursion VM problems 95% done, I think. I
hope to finish it off tonight and will put a jar into whiteboard so we can
work it over before I commit the code. It should solve all of our issues
except the idea of local context vars, and that could be controlled via a
switch that prevents VMs from adding new references to the 'global' context
(you can still use them for scratchwork in-scope in the VM).
That's something we should talk about.
Granted that isn't the same flexibility as the notion of declaring local
variables with a formal #local(), but if we decide we really, really need
that sort of thing, declaring locals via #locak() with everything else
assumed to be global, it would be trivial to add on.
geir
