You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by dl...@apache.org on 2001/08/10 03:14:15 UTC
cvs commit: jakarta-turbine/src/java/org/apache/turbine/util/parser DefaultParameterParser.java
dlr 01/08/09 18:14:15
Modified: src/java/org/apache/turbine/util/parser
DefaultParameterParser.java
Log:
Used more descriptive variable name.
Revision Changes Path
1.14 +8 -8 jakarta-turbine/src/java/org/apache/turbine/util/parser/DefaultParameterParser.java
Index: DefaultParameterParser.java
===================================================================
RCS file: /home/cvs/jakarta-turbine/src/java/org/apache/turbine/util/parser/DefaultParameterParser.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -u -r1.13 -r1.14
--- DefaultParameterParser.java 2001/08/01 15:44:25 1.13
+++ DefaultParameterParser.java 2001/08/10 01:14:15 1.14
@@ -89,7 +89,7 @@
* @author <a href="mailto:ilkka.priha@simsoft.fi">Ilkka Priha</a>
* @author <a href="mailto:jon@clearink.com">Jon S. Stevens</a>
* @author <a href="mailto:sean@informage.net">Sean Legassick</a>
- * @version $Id: DefaultParameterParser.java,v 1.13 2001/08/01 15:44:25 jvanzyl Exp $
+ * @version $Id: DefaultParameterParser.java,v 1.14 2001/08/10 01:14:15 dlr Exp $
*/
public class DefaultParameterParser
extends BaseValueParser
@@ -223,27 +223,27 @@
try
{
StringTokenizer st = new StringTokenizer(req.getPathInfo(), "/");
- boolean name = true;
+ boolean isNameTok = true;
String pathPart = null;
- while(st.hasMoreTokens())
+ while (st.hasMoreTokens())
{
- if ( name == true )
+ if (isNameTok)
{
tmp = URLDecoder.decode(st.nextToken());
- name = false;
+ isNameTok = false;
}
else
{
pathPart = URLDecoder.decode(st.nextToken());
- if ( tmp.length() != 0 )
+ if (tmp.length() > 0)
{
add (convert(tmp), pathPart);
}
- name = true;
+ isNameTok = true;
}
}
}
- catch ( Exception e )
+ catch (Exception e)
{
// If anything goes wrong above, don't worry about it.
// Chances are that the path info was wrong anyways and
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-turbine/src/java/org/apache/turbine/util/parser DefaultParameterParser.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
John McNally <jm...@collab.net> writes:
> dlr@apache.org wrote:
> >
> > - if ( tmp.length() != 0 )
> > + if (tmp.length() > 0)
> > {
>
> Anyone know one way or another if there is any performance hit to using
> > 0 over != 0 when comparing a function return value that is known never to be negative? Probably inconsequential, but it just seems like the != would be a cheaper operation.
I wouldn't think so. In x86 assembler, both "equal" and "greater
than" are single op codes. I don't see why this should be any
different in a x86 JVM.
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-turbine/src/java/org/apache/turbine/util/parser
DefaultParameterParser.java
Posted by John McNally <jm...@collab.net>.
dlr@apache.org wrote:
>
> - if ( tmp.length() != 0 )
> + if (tmp.length() > 0)
> {
Anyone know one way or another if there is any performance hit to using
> 0 over != 0 when comparing a function return value that is known never to be negative? Probably inconsequential, but it just seems like the != would be a cheaper operation.
john mcnally
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org