Jose is pointing to a problem with the dropping using chained contexts.
So maybe the keeping the Context API simple is a *too* hard limitation.
I originally said "dropping would work for me", but this does not
seem to apply for all applications. Vel should be simple but general
enough to avoid contradictions.
Note that I'm not from the "no-null lobby", but am a "NULL friend" :)
The only case I would rather see a NULL value is when I want to debug
the context and list the "keys = primitive-values (or class-name)".
Here it is usefull to see that foo exists and is invalid: "foo = NULL".
Now for the context chaining it will be necessary to differentiate
between a no-value and no-definition states. So there is a reason
for NULL values (Hi NULL friends :).
Will VMs use context chaining? If so, will a macro be able to
update higher level contexts? I guess the best way to go is to have
a TransparentContext, where updates affect the parent contexts;
and a LocalContext (= VelocityContext?) instatiating a chaining by
a #local directive (as proposed in another thread) that makes all
#sets only affect the local one. Then safe VMs should allways
contain a #local...#end, which can be left away for speed purposes
and/or when it does not do any dangerous sets.
>[snip]
> > > That is an issue we have to work out. I think no, we should treat the
> > > chained contexts as 'read only'. Since you can't put() into a chained
> > > context (the put() operation only affects the local or 0th level
> > > context), you can't remove() either.
> > >
> >
> > Well this is exactly my point. Christoph's solution of simply removing the
> > context entry does not work. Why?, because it would expose the old value
> > after the set operation which, I think is the more confusing behavior we can
> > have.
>
> Hm. It would expose a value in a chained context if it exists.
Well, who defines which context implementation is in effect? It seems that
the AbstractContext shall allow NULL values, and the actual implementation
should refuse it if not proper; or eventually propagate it to the parent
context if it cannot handle it locally (after a local remove).
>
> > > > I really think NULL values on the right should be valid values.
>[snip]
> > probably the most useful information that they provide is that a valid
> > #set operation was performed and that it produced no value. Hence it can be
> > used to differentiate between no-value and no-definition.
+1
>
> Hm. I agree that there is a difference, and to some degree it's
> important. I wonder, though, if its more important to keep things
> simple for the template creator. You do quite advanced templates. I
> don't think the average user would come close to what you come up with.
The template creator does not see the difference.
If he cares he could implement somehow a containsKey (e.g. #ifdefined)
to check the difference between a no-value and a no-definition.
>[snip]
> It already is, actually, when you think about it. You can have
> $foo.woobiewoobiewoobie in a template, and if $foo is in the context,
> and is a string "warg", then it would render as warg.woobiewoobiewoobie.
>
> Now, this is different in a #set directive, as the .woobie... is no
> longer treatable as schmoo, because the RHS of the = in a #set() must
> not have dangling schmoo.
Wow! warg.woobiewoobiewoobie is great (but dangerous to typos or
developers changing context classes). I would reccomend to do
"${foo}.woobiewoobiewoobie" to be sure to allways get the right
thing ;)
:) Christoph
