> BTW, I found this advice
> http://docs.sun.com/app/docs/doc/819-3681/abebf?a=view#abebm is there any
> performance advantages (I
reckon
> it's would anyway be marginal) ?
Ok, forget it :
http://www-128.ibm.com/developerworks/java/library/j-jtp1029.html
Jacques
OK, done finally, needed a cast
return "true".equalsIgnoreCase((String)AIMProperties.get("testReq"));
When there are no conventions, it's always a trade off between readability
(using more verbose forms) and conciness. Sometime
conciness is better, it's the case here
BTW, I found this advice
h
Yes, true. I saw it when Jonathon send his message and then forgot. So it will
simpley be
return "true".equalsIgnoreCase(AIMProperties.get("testReq"));
Finally Scoot was right : a bit miserable :o) Though, I was not aware of
equalsIgnoreCase... Lesson learned...
Jacques
De : "Jacopo Cappella
Jacques Le Roux wrote:
De : "Jacopo Cappellato" <[EMAIL PROTECTED]>
Jonathon -- Improov wrote:
Why not this?
+1
I will dot it soon using my preferred one (mix of Jonathon's and Adrian's)
return testReq == null ? false :
"true".equalsIgnoreCase(AIMProperties.get("testReq"));
You can do the
I find it quite intersting :p
Jacques
De : "Scott Gray" <[EMAIL PROTECTED]>
> Perfect, could someone commit it and put this poor thread out of it's misery
> :-)
>
> Scott
>
> On 20/12/2007, Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
> >
> > Why not this?
> >
> > "true".equalsIgnoreCase(AIMP
De : "Jacopo Cappellato" <[EMAIL PROTECTED]>
> Jonathon -- Improov wrote:
> > Why not this?
> +1
I will dot it soon using my preferred one (mix of Jonathon's and Adrian's)
return testReq == null ? false :
"true".equalsIgnoreCase(AIMProperties.get("testReq"));
> > That would work no matter what c
Jonathon -- Improov wrote:
Why not this?
"true".equalsIgnoreCase(AIMProperties.get("testReq"));
+1
That would work no matter what case, upper or lower or mixed. Unless we
don't want case to be ignored?
Yes, this is one doubt I have: who is setting the "testReq" parameter?
Why it was i
Perfect, could someone commit it and put this poor thread out of it's misery
:-)
Scott
On 20/12/2007, Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
>
> Why not this?
>
> "true".equalsIgnoreCase(AIMProperties.get("testReq"));
>
> That would work no matter what case, upper or lower or mixed. Unles
Jacopo Cappellato sent the following on 12/19/2007 3:18 AM:
> BJ Freeman wrote:
>> first, the orgninal code would never evaluate since lowercase true is
>> correct.
>> return ("TRUE".equals((String) should be return ("true".equals((String)
>
> ok
>
>> second if the properties is null it would n
Why not this?
"true".equalsIgnoreCase(AIMProperties.get("testReq"));
That would work no matter what case, upper or lower or mixed. Unless we don't
want case to be ignored?
The above is also better than:
testReq.equalsIgnoreCase("true");
The 1st statement doesn't require any testing of "testR
BJ Freeman wrote:
first, the orgninal code would never evaluate since lowercase true is
correct.
return ("TRUE".equals((String) should be return ("true".equals((String)
ok
second if the properties is null it would not evaluate correct, and
there is not use using more cpu cycles to evaluate.
The main motivation was that this would never evaluate to test mode,
which is import when first bringin this code online.
Jacopo Cappellato sent the following on 12/19/2007 2:09 AM:
> Jacques, BJ,
>
> after having read the comments in the issue and the commit logs I really
> don't understand what
first, the orgninal code would never evaluate since lowercase true is
correct.
return ("TRUE".equals((String) should be return ("true".equals((String)
second if the properties is null it would not evaluate correct, and
there is not use using more cpu cycles to evaluate.
if(testReq.equals("TRUE")) t
Big +1 here, we should never commit anything that we don't completely
understand, it should almost be as if we had written the code ourselves. A
committer is answerable for his commits not the contributor.
Regards
Scott
On 19/12/2007, Jacopo Cappellato <[EMAIL PROTECTED]> wrote:
>
> Jacques Le R
Jacques, BJ,
after having read the comments in the issue and the commit logs I really
don't understand what was the bug and how this patch is going to fix it.
Please, see my comments below:
Jacques Le Roux wrote:
David,
1. I had already refactored the code, please see trunk rev. 605190 and
Why was the 1-liner code removed? The original was concise, and was able to take null values
without blowing up.
Or if we're worried about class cast exceptions:
return "TRUE".equals(AIMProperties.get("testReq"));
Jonathon
David E Jones wrote:
1. Bad code formating
2. Makes the default true,
PL lines
> >>code, I'm used to play with these kind of boolean
stuffes,
> >
> > I
> >
> >>must say that from this POV, APL is more fun than any other languages ;o)
> >>
> >>Jacques
> >>
> >>- Mes
s
- Message d'origine -
De : "Adrian Crum" <[EMAIL PROTECTED]>
À :
Envoyé : mardi 18 décembre 2007 19:26
Objet : Re: svn commit: r605186 -
/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/authorizedotnet/AIMPaymentServices.java
Plus,
h these kind of boolean stuffes,
I
> must say that from this POV, APL is more fun than any other languages ;o)
>
> Jacques
>
> - Message d'origine -
> De : "Adrian Crum" <[EMAIL PROTECTED]>
> À :
> Envoyé : mardi 18 décembre 2007 19:26
>
uages ;o)
Jacques
- Message d'origine -
De : "Adrian Crum" <[EMAIL PROTECTED]>
À :
Envoyé : mardi 18 décembre 2007 19:26
Objet : Re: svn commit: r605186 -
/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/authorizedotnet/AIMPaymentServi
Not both, just one had, I have already dealed with that in trunk rev. 605190
and release4.0 rev. 605189
Jacques
De : "BJ Freeman" <[EMAIL PROTECTED]>
> that does not look like my patch.
> mine has an uppcase in it.
>
>
> David E Jones sent the following on 12/18/2007 10:19 AM:
> > 1. Bad code fo
David,
1. I had already refactored the code, please see trunk rev. 605190 and
release4.0 rev. 605189. BTW there are tons and tons of such
bad code formating eveywhere in the code...
2. I let BJ answer, personally I would put false but I did not know why BJ put
this so I let it.
3. I even could h
that does not look like my patch.
mine has an uppcase in it.
David E Jones sent the following on 12/18/2007 10:19 AM:
> 1. Bad code formating
> 2. Makes the default true, is that what we really want?
> 3. If 2 is true then should use more compact and easy to read,
> like if != false instead of if
Plus, you can eliminate one if() construct:
if (testReq != null) {
return "TRUE".equals(testReq.toUpperCase());
}
-Adrian
David E Jones wrote:
1. Bad code formating
2. Makes the default true, is that what we really want?
3. If 2 is true then should use more compact and easy to read,
like
1. Bad code formating
2. Makes the default true, is that what we really want?
3. If 2 is true then should use more compact and easy to read,
like if != false instead of if = true
-David
On Tue, 18 Dec 2007 11:37:55 -
[EMAIL PROTECTED] wrote:
> Author: jleroux
> Date: Tue Dec 18 03:37:47 20
25 matches
Mail list logo
