Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
Antonio Gallardo wrote:
[EMAIL PROTECTED] dijo:
joerg 2004/03/03 11:47:35
Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding
RepeaterJXPathBinding.java
Log:
clean up: removed unused code (for reverting changes we have CVS, so
please remove old stuff always), JavaDoc added, comments fixed;
changed isNullAllListElements() = isAnyListElementNotNull(): the
duplicate negation at usage time breaks my brain ;-)
This depends of the POV you see it:
isNullAllListElements() - This is not a negation. It check if :
All elements on the List are null. Where is the negation?
isAnyListElementNotNull() - Here is a negation Not null :-D
Generally speaking, negative forms should be avoided, as their
interpretation may be difficult depending on people's linguistic
background. I used to work with Japanese people long time ago, and I'm
sure this name, even with a single negation, would be very hard for them
to understand.
So what about hasNonNullElements()?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
Sylvain Wallez dijo: Antonio Gallardo wrote: [EMAIL PROTECTED] dijo: joerg 2004/03/03 11:47:35 Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java Log: clean up: removed unused code (for reverting changes we have CVS, so please remove old stuff always), JavaDoc added, comments fixed; changed isNullAllListElements() = isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) This depends of the POV you see it: isNullAllListElements() - This is not a negation. It check if : All elements on the List are null. Where is the negation? isAnyListElementNotNull() - Here is a negation Not null :-D Generally speaking, negative forms should be avoided, as their interpretation may be difficult depending on people's linguistic background. I used to work with Japanese people long time ago, and I'm sure this name, even with a single negation, would be very hard for them to understand. I agree. So what about hasNonNullElements()? The problem again is the hidden Non. This is a kind of negative. Look as the standard isNull() function. Why it is not isNotNull()? Because there is a negation. Then, the original function name is better to me: isNullAllListElements() or areNullAllListElements() To me it clearly states what we had in mind. Goerg changed the function name (and behavior) to write: if (isAnyListElementNotNull(...)) instead of if (!isNullAllListElements(...)) As a rule I try to avoid negation inside the names. In the case hasNonNullElements(), we can write also: if (hasNonNullElements()) Interesting is that the method need to check for each element if the value is null. At the end, I think I am not the best to decide the best name of the function. :-D Best Regards, Antonio Gallardo.
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
On 04.03.2004 09:31, Sylvain Wallez wrote: changed isNullAllListElements() = isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) This depends of the POV you see it: isNullAllListElements() - This is not a negation. It check if : All elements on the List are null. Where is the negation? isAnyListElementNotNull() - Here is a negation Not null :-D Hmm, that's true. But what I meant was the usage of !isNullAllListElements and ListElement != null inside the function. What you are really testing for is the availableness/usability of the list for unique identification. So the function itself should not return true if it only contains nulls. Generally speaking, negative forms should be avoided, as their interpretation may be difficult depending on people's linguistic background. I used to work with Japanese people long time ago, and I'm sure this name, even with a single negation, would be very hard for them to understand. So what about hasNonNullElements()? Yes, this might be more obvious/understandable than any and not in my version. Joerg
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
In fact we can call it: isValidKey(...) --- I prefer this one over the below name. isValidUniqueRowId(...) The other names are too specific to what the function do. Sometimes it is good to call the functions by what solve and not by how is the internal implementation (using List, Set or whatever). WDYT? Best Regards, Antonio Gallardo. Joerg Heinicke dijo: On 04.03.2004 09:31, Sylvain Wallez wrote: changed isNullAllListElements() = isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) This depends of the POV you see it: isNullAllListElements() - This is not a negation. It check if : All elements on the List are null. Where is the negation? isAnyListElementNotNull() - Here is a negation Not null :-D Hmm, that's true. But what I meant was the usage of !isNullAllListElements and ListElement != null inside the function. What you are really testing for is the availableness/usability of the list for unique identification. So the function itself should not return true if it only contains nulls. Generally speaking, negative forms should be avoided, as their interpretation may be difficult depending on people's linguistic background. I used to work with Japanese people long time ago, and I'm sure this name, even with a single negation, would be very hard for them to understand. So what about hasNonNullElements()? Yes, this might be more obvious/understandable than any and not in my version. Joerg
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
On 03.03.2004 20:47, [EMAIL PROTECTED] wrote: joerg 2004/03/03 11:47:35 Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java Log: clean up: removed unused code (for reverting changes we have CVS, so please remove old stuff always), JavaDoc added, comments fixed; changed isNullAllListElements() = isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) For one case there is now another behaviour: if the list is empty now false will be returned (as before, but there the function tested the opposite). I don't know if this breaks anything, it was just for logical reasons: isNullAllListElements() returning false I expect to get one list element which is not null, which is not the case for empty list. Antonio, I guess you are the only one using it at the moment. Can you test it please? Joerg
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
[EMAIL PROTECTED] dijo: joerg 2004/03/03 11:47:35 Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java Log: clean up: removed unused code (for reverting changes we have CVS, so please remove old stuff always), JavaDoc added, comments fixed; changed isNullAllListElements() = isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) This depends of the POV you see it: isNullAllListElements() - This is not a negation. It check if : All elements on the List are null. Where is the negation? isAnyListElementNotNull() - Here is a negation Not null :-D Best Regards, Antonio Gallardo.
