JBossDeveloper

Hmm, so should we re-introduce option-overloaded methods?

We're looking at about 10 methods in Cache, 20 in Node and about another 20 in NodeSPI. We'd be doubling these to 20, 40 and 40.

If this is what needs to happen then ok, but as far as possible I'd like the interfaces to be kept lean and simple. OTOH, I do agree with the ugliness and potential brittleness of setting an option before an invocation.

The only other options I can think of are:

1) Use varargs put(fqn, key, value, Option...). The problem with this approach is that eclipse treats varags like an array when doing tab completion, so you have to know that you dont need the parameter.

2) Break the API for each element into 2 interfaces. Then add a getAdvanced() or something to return the advanced versions of the methods. This of course only reduces the methods in the simple case for the user. The implementation still has to implement both methods.

-Jason

I like the varargs approach, except that it uses varargs to make a param optional (1 instance or none) rather than several instances, which is what varargs were desigend for (and hence IDEs representing them as such). A *bit* hacky, IMO.

The other approach is to allow people to pass in many Options, like Jason mentioned, such as node.get(key, Option.FORCE_WRITE_LOCK, Option.FAIL_SILENTLY) but this means we'd need to aggregate the options passed in into a single one - not hard to do, just annoying and defeats the purpose of an Option class.

Thoughts?