Jose Alberto Fernandez wrote:
>
> > From: Christoph Reck [mailto:[EMAIL PROTECTED]]
> >
> > Getting there...
> >
> > A valid solution for me is to "Drop the key from the context
> > if the value is null".
> >
>
> How will this work with the new chained Contexts that have been proposed?
> Does it goes and removes any previous occurrence in the chain? Will it just
> make any previous occurence available?
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.
> I really think NULL values on the right should be valid values.
Why? What do you get with that? Can you give me an example? I just
don't see where this would be useful information. Don't read this as
some sort of challenge - I am just curious where this would be useful to
you.
If you believe in the no-null philosophy, I think that christoph put it
very well :
"Context is a [collection] of objects accessible by a name (key). NULL
is not a object, therefore
cannot be in the context. Setting something to NULL, removes the key
from the context."
If not, the question from the no-nulll camp is "why?".
> See some other comments below:
>
> > "Geir Magnusson Jr." wrote:
> > >
> > > Christoph :
> > > > My experience shows me these situations where a NULL can happen.
> > >
> > > > a) The template designer has written an invalid identifyer:
> > > > #set( $foo = $bar.woobie )
> > > > where getWoobie() does not exists. here it is sufficient that
> > > > its logged...
> > >
> > > Yes, that will be logged. It is actually checked before
> > it's shoved into
> > > the context, so the only issue there is that $foo is still
> > not in the
> > > context if it wasn't, or unchanged if it is. Maybe to
> > support the semantics
> > > of 'no null references' we just remove $foo from the context ?
> >
>
> Shouldn't we distinguish between NULL results and NON EXISTING results?
I dunno. I think that if you were writing a compiler, you'd better.
But in a simple template language meant for content design and
presentation? At a simple level, it's hard to explain the difference,
especially in the problem domain of the template author.
"Is it there?"
"Well, what do you mean by 'there' ?"
It gets Clinton-esque quickly :)
> I would argue that in the example above, what we have is an error
> on the evaluation of #set since getwoobie() does not exists. In such a case
> we should not only log but we could also ignore the operation completely.
Well, as Christoph likes to point out, validly, that you then have
unexpeted results or difficulty dealing with that in the template. I
think that would make it harder to write robust templates, and that's an
important factor to consider, I think, if you are authoring VMs for
general use in a design group or something.
> The same for #set($a = $a + "two"). This is an error.
That is an error, and is logged as such, as a type incompatibility for
the operation. Right now, $a is not altered in the context, as that is
our convention, and that's what we are talking about changing.
> > If you make 'no null references' configurable some others
> > will scream,
> > saying this will counteract velocimacro libraries...
> >
> > >[snip]
> > > right. Hm. Maybe if you do what amounts to a #set( $foo =
> > <null value
> > > returned from something> ) then we remove $foo from the
> > context if it is
> > > there? That would support the semantics, be predictable, etc.
> >
> > +1
>
> As I said before what does this means in the case of chained contexts.
Dunno yet. I would think that we would not want it to affect the
chainged contexts, as they are 'read only'. I mean, when you put()
something that is in the chain (not the 0th level), you don't alter it,
just mask it.
And since a #set($foo = .....) is affecting the 0th level context
storage (the 'local context'?) then altering the 0th level context seems
appropos, and leaving the chained contexts alone. I think that keeping
the chained contexts read-only is important. I guess, people could just
make their own context implementation that they lock after they load it,
but that kinda sucks.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
