Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
Message-ID: <529F0006.9040908@apache.org>
Date: Wed, 04 Dec 2013 11:12:22 +0100
From: Herbert Duerr <hdu@apache.org>
User-Agent: generic
MIME-Version: 1.0
To: dev@openoffice.apache.org
Subject: Re: Improvements of OUString
References: <529D929D.4040404@googlemail.com> <529DA5D5.1040601@apache.org>
 <529DC854.4090304@googlemail.com> <529DDD73.6010001@apache.org>
 <529EC9A8.2090802@pitonyak.org>
In-Reply-To: <529EC9A8.2090802@pitonyak.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 04.12.2013 07:20, Andrew Douglas Pitonyak wrote:
> As Herbert said, this directly expresses what it checks. I would add
> "and it reads better".
>
> There are other reasons, however; for example, depending on the
> implementation, it may be significantly faster than comparing against
> the length. For one implementation it may not matter, but, if you change
> the implementation in the future, it may.

Yes. Especially considering that the "length of a string" is somewhat 
ambiguous. Currently getLength() returns the number of codepoints in the 
strings encoding (e.g. UTF-16).

But one could also reasonably define the length of a string as the 
number of unicode codepoints. This number is different from getLength() 
if unicode surrogates were involved or unicode normal forms were taken 
into consideration.

> Uniformity is another possible reason (assuming other classes also
> implement isEmpty()). If you become used to using the expressive form
> (ie, using isEmpty() rather than comparing size), then you can leave
> optimizing the call to the class implementer rather than worrying about
> the correct way to do it.

For historic reasons the STL and TR1 containers use "empty()" to check 
for emptiness and clear() to empty the container.

In the previous sentence I intentionally used "empty" once as an 
adjective and once as a verb to show that the method name "empty()" is 
ambiguous. Therefore I preferred to use the Java inspired method name 
"isEmpty()" for checking the emptiness of a string.

> I have seen empty strings checked by comparing
> the length to zero, and even using a string compare against an empty
> string.

Indeed: In our current codebase there are all kinds of variants for this 
simple check. E.g.
	aString == OUString()
	aString.equalsAscii("")
	aString.equals( OUString())
	aString.compareTo( OUString(""))
	aString.compareToAscii( "")
	aString.getLength() == 0
	aString.getLength() < 1
and the related checks:
	aString.getLength() > 0
	aString.getLength() >= 1
Also there was the now already eliminated buggy variant
	if( aString)

With the new method all these could be cleanly consolidated.

I must admit that the long discussion thread over the seemingly simple 
new method "isEmpty()" is somewhat scary to me...

Herbert


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org