You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2000/12/28 19:31:34 UTC
logical stuff
There are a few issues pending that we should talk about. Some came
from watching turbine list, some from discussion (thanks, Fedor).
1) What do we do about determining if a reference is null in VTL?
Currently, we can use #if(), but that's misleading - if the reference is
in the context, is a boolean, and is false, than we get the same result
as if the thing wasn't in there. So thats no good. So we need
something that is clear about what it does, and what the result means.
Some suggestions :
- use something like : #if( $foo == null )
I like this one, but Fedor noted we might want to keep
the concept of null out of things, although I think it
is a keyword in javascript, so it isn't that foreign.
- or #ifdefined( $foo ) or #ifdef( $foo )
This is trivially easy to do.
- or another operator : #if( ?$foo )
2) Should we allow the following aliases for the logicals :
logical AND : '&&' (current), '&', 'AND', 'and'
logical OR : '||' (current), '|', 'OR', 'or'
equality : '==' (current), '=', 'eq' ?
Since there is little or no chance of offering bitwise operations in
VTL, this might remove some confusion with designers (if there is any).
I am indifferent tending to negative on this, as I am so used to them
being different in Java, C++, C, etc, but for designers, that might not
be a problem.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: logical stuff
Posted by Christoph Reck <Ch...@dlr.de>.
here my 2c:
> 1) What do we do about determining if a reference is null in VTL?
>[snip]
> - use something like : #if( $foo == null )
+0, but make it uppercase NULL to reflect the constantness of it.
>[snip]
> - or #ifdefined( $foo ) or #ifdef( $foo )
> This is trivially easy to do.
but not necessary.
I think instead of defining implicetely a NULL constant make it
simple and use a real directive $NULL. Does #if($foo == $bar) work
already when both are null?
>
> - or another operator : #if( ?$foo )
-1, I agree: "Hell no. No PERL!"
>
> 2) Should we allow the following aliases for the logicals :
-1 on overloading.
Keep it simple '&', '|', and '=' do the job fine.
:) Christoph
---
Happy new Year to all of you!
Re: logical stuff
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> on 12/28/2000 10:31 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> > There are a few issues pending that we should talk about. Some came
> > from watching turbine list, some from discussion (thanks, Fedor).
> >
> > 1) What do we do about determining if a reference is null in VTL?
> >
> > Currently, we can use #if(), but that's misleading - if the reference is
> > in the context, is a boolean, and is false, than we get the same result
> > as if the thing wasn't in there. So thats no good. So we need
> > something that is clear about what it does, and what the result means.
> >
> > Some suggestions :
> >
> > - use something like : #if( $foo == null )
> > I like this one, but Fedor noted we might want to keep
> > the concept of null out of things, although I think it
> > is a keyword in javascript, so it isn't that foreign.
>
> +0. This is my preference, however (and hence the 0 score), what is wrong
> with:
>
> #if ( $objectUtils.isNull ($foo) )
Nothing really, but then we have to have these utils floating about
where it's a simple thing for VTL to do for us. VTL already handles
null refs already, in #if(), in rendering, in logicals, in the simple
mathematical ops.
I don't want to change how #if() works. I just want to clear the fog on
the problem of how to tell if a reference is null.
> I'm afraid that we *might* be venturing into adding a bit to much
> programming ability into VTL by adding the ability to check for null.
Except we already do that for other reasons : the 'quiet reference' idea
is one example, although implicitly.
Seems like people need a clear, explicit way to working with references
not in the context.
> > - or another operator : #if( ?$foo )
>
> Hell no. No PERL!
:)
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: logical stuff
Posted by Jon Stevens <jo...@latchkey.com>.
on 12/28/2000 10:31 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> There are a few issues pending that we should talk about. Some came
> from watching turbine list, some from discussion (thanks, Fedor).
>
> 1) What do we do about determining if a reference is null in VTL?
>
> Currently, we can use #if(), but that's misleading - if the reference is
> in the context, is a boolean, and is false, than we get the same result
> as if the thing wasn't in there. So thats no good. So we need
> something that is clear about what it does, and what the result means.
>
> Some suggestions :
>
> - use something like : #if( $foo == null )
> I like this one, but Fedor noted we might want to keep
> the concept of null out of things, although I think it
> is a keyword in javascript, so it isn't that foreign.
+0. This is my preference, however (and hence the 0 score), what is wrong
with:
#if ( $objectUtils.isNull ($foo) )
I'm afraid that we *might* be venturing into adding a bit to much
programming ability into VTL by adding the ability to check for null.
Also, I would prefer it be all uppercase NULL as it is a constant and stands
out more that way.
> - or #ifdefined( $foo ) or #ifdef( $foo )
> This is trivially easy to do.
-1. It adds confusion with #if. People will wonder why they want to use
either one.
> - or another operator : #if( ?$foo )
Hell no. No PERL!
> 2) Should we allow the following aliases for the logicals :
>
> logical AND : '&&' (current), '&', 'AND', 'and'
>
> logical OR : '||' (current), '|', 'OR', 'or'
>
> equality : '==' (current), '=', 'eq' ?
>
> Since there is little or no chance of offering bitwise operations in
> VTL, this might remove some confusion with designers (if there is any).
> I am indifferent tending to negative on this, as I am so used to them
> being different in Java, C++, C, etc, but for designers, that might not
> be a problem.
-1. I think designers understand && and || and ==. I find that using AND/OR
is annoying and somewhat confusing sometimes. I am also against adding a lot
of "alternative" ways of doing things (in other words, overloading is bad).
Again, this also falls under my dislike of adding NULL.
thanks,
-jon