Which ended up looking like:
public static enum PARAM { escapePlus };
private EnumSet<PARAM> params;
public UnicodeUnescaper(PARAM... params) {
if(params.length > 0) {
this.params = EnumSet.copyOf(Arrays.asList(params));
}
}
public boolean isSet(PARAM p) {
return (params == null) ? false : params.contains(p);
}
Opinions very, very much desired. Tempted to extend EnumSet to
simplify a little of the null protection etc. ParamSet<P> and
protecting against empty arrays and null params. Maybe looking like:
public static enum PARAM { escapePlus };
private ParamSet<PARAM> params = new ParamSet<PARAM>();
public UnicodeUnescaper(PARAM... parameters) {
this.params.add(parameters);
}
public boolean isSet(PARAM p) {
return params.contains(p);
}
To a user this looks like:
uu = new UnicodeUnescaper(UnicodeUnescaper.PARAM.escapePlus);
with the advantage for us being that we can add options to a class
without API problems.
Hen
On Sun, Oct 18, 2009 at 1:04 PM, Henri Yandell <flame...@gmail.com> wrote:
> On Sun, Oct 18, 2009 at 12:49 PM, Henri Yandell <flame...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
