On 08/29/2015 06:59 AM, Gilles wrote:
On Fri, 28 Aug 2015 21:25:12 -0500, Ole Ersoy wrote:
On 08/28/2015 04:29 PM, Gilles wrote:
On Fri, 28 Aug 2015 11:48:28 -0500, Ole Ersoy wrote:
This is a side note. In the class Incrementor there's a
MaxCountExceededCallback that triggers the MaxCountExceededException.
It might make sense to place the code that throws the exception in a
static utility method inside the exception, eliminating the cb
property, the MaxCountExceededCallback interface, and corresponding
Incrementor constructor. So we could do:
public void incrementCount() throws MaxCountExceededException() {
MaxCountExceededException.throw(++count, max);
}
The callback is intended to let the user choose which action the counter
exhaustion should trigger. IIRC your proposal, this would not be possible
anymore.
OK - Got it. I too easily associated the 'MaxCountExceeded' callback
with the MaxCountExceededException. My first thought was that (Even
though the doc says otherwise) if the max is exceeded, then this is
bad, and so an exception should be triggered. How about removing the
MaxCountExceededException
?
The exception could be used independently of the callback interface.
If the IntegerSequence becomes an IntegerSequenceEmitter, and in general
commons math follows a pattern of listening for events like `start`,
`increment`, and `end` then we will never exceed the max.
What would be the gain?
- Shorter implementation
- No exceptions
- Event emitter pattern (Which is a popular design pattern for light coupling
of objects).
- The event emitter can be extended to add more events
- We can skip checking `canIncrement()`
- It introduces a different way of thinking about algorithm design
[Seems overkill for the counter functionality as currently used within CM.]
I think we will gain utility, simplify both current and future code, and
possibly establish a better development pattern for algorithms if we use an
exception free IntegerSequenceEmitter.
P.S.
Plus one for "Incrementor(long start, long max).
What do you think of the new API
https://issues.apache.org/jira/browse/MATH-1259
?
I think it should work like this:
=======================
Incrementor.build().setStart(start).
setNumberOfSteps(numberOfSteps)
.stepSize(stepSize).
setCallback(CallbackEnum.START, startCB).
seCallback(CallbackEnum.END, endCB).
setCallback(CallbackEnum.INCREMENT, incrementCB).
down()
||
up();
=======================
If down is called at the end then we get a sequence like 15, 10, 5...If up() is
called then ...
Callbacks are optional. We can call increment or increment(10) indefinitely
without an exception being thrown. We should be able to retrieve the number of
increments left, as is included in the current design.
It's up to the developer to calculate the number of steps. So for example if
the max is 17 and the start is 5 and the step size is 5, then the developer has
to decide if she wants 3 or 4 steps completed.
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
