> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
>
> 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.
>
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.
> > 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.
>
Well, 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.
My point is not that much how we treat null values (what we do when we found
one, #if, etc.) but how the Contexts manage them.
> 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?".
>
I can live with Velocity treating NULL values like there was no value there
which in most cases is the same as if they were not defined in the Context.
However, as in the case of chaining it is important to differentiate between
non-existant and not-defined.
> > 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.
>
Why should be invoking a non existing property or method treated any
different.
Jose Alberto
