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 20:04:14 GMT
On Sun, Oct 18, 2009 at 12:49 PM, Henri Yandell <flamefew@gmail.com> wrote:

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

Rambling out loud.

Better (for API scaling):

enum FooParam { various PARAM options}

constructor:  Foo(FooParam... fp) {  this.options =
EnumSet.copyOf(Collections.asList(fp)); }

That would work quite nicely to replace all the painful boolean
constructor parameters. That leaves us then needing a way to scale
this for a single initial parameter:

With a recompile, you could have an Object called PARAM and replace it
with a FooParam.PARAM later on of type enum:FooParam, but I'm assuming
that would be an error at runtime. So for runtime API scaling you
would need to set the enum up from the start. Ideally it wants to be
in the same class/file though, which means an inner class so you can
make it public. So:

new Foo(Foo.PARAM.escapingPlus)

You could also have a single argument constructor to start with, but
again runtime is probably unhappy when you switch (or overload -
compile error?) with varargs.

Is it a worthwhile pattern to avoid rampant booleanism in a minority
of classes? Not convinced.

Hen

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


Mime
View raw message