commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: svn commit: r826370 - in /commons/proper/lang/trunk/src: java/org/apache/commons/lang/text/translate/UnicodeUnescaper.java test/org/apache/commons/lang/text/translate/UnicodeUnescaperTest.java
Date Sun, 18 Oct 2009 19:49:53 GMT
On Sun, Oct 18, 2009 at 4:28 AM, sebb <sebbaz@gmail.com> wrote:
> On 18/10/2009, bayard@apache.org <bayard@apache.org> wrote:
>> Author: bayard
>>  Date: Sun Oct 18 07:25:59 2009
>>  New Revision: 826370
>>
>>  URL: http://svn.apache.org/viewvc?rev=826370&view=rev
>>  Log:
>>  Implementing an option to UnicodeUnescaper in which the syntax '\u+0047' is supported.
By default it remains unsupported to match Java's method of parsing. Request in LANG-507
>>
>>  Modified:
>>     commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/translate/UnicodeUnescaper.java
>>     commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/translate/UnicodeUnescaperTest.java
>>
>>  Modified: commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/translate/UnicodeUnescaper.java
>>  URL: http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/translate/UnicodeUnescaper.java?rev=826370&r1=826369&r2=826370&view=diff
>>  ==============================================================================
>>  --- commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/translate/UnicodeUnescaper.java
(original)
>>  +++ commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/translate/UnicodeUnescaper.java
Sun Oct 18 07:25:59 2009
>>  @@ -26,6 +26,15 @@
>>   */
>>   public class UnicodeUnescaper extends CharSequenceTranslator {
>>
>>  +    private boolean escapingPlus = false;
>>  +
>>  +    public void setEscapingPlus(boolean b) {
>>  +        this.escapingPlus = b;
>>  +    }
>>  +    public boolean isEscapingPlus() {
>>  +        return this.escapingPlus;
>>  +    }
>>  +
>
> Would it not be better to make the class immutable (and thread-safe)
> by providing the setting as a constructor parameter, rather than as
> set/get methods?

Don't know - putting it in the constructor doesn't scale well API-wise
as more options are added.  I'm not the biggest fan of that style of
API and it makes for less readable code.

new Thing(true) vs new Thing().setEscapingPlus(true).

2nd is an ugly API, mostly due to some brainwashed need to look like a
Java bean. I'd much rather have:   new Thing().escapingPlusOn(). I
guess the constructor approach could be: new Thing(Thing.ESCAPE_PLUS)
leading, potentially, to the stunning C API of:  new
Thing(Thing.ESCAPE_PLUS & Thing.ESCAPE_MINUS).

Oh for named parameters:     new Thing( escapePlus => true,
escapeMinus => true).

Fair enough on the threading though. I'll move to constructor as I
can't think of anything better.

Hen

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


Mime
View raw message