On Sat, 29 Aug 2015 15:56:38 -0500, Ole Ersoy wrote:
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
Of what?
- No exceptions
Hmm, in this case, the main usage in CM is to throw an exception
when an iterative algorithm exhausts the counter...
- 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()`
But the user code must listen to the events, instead. No?
- It introduces a different way of thinking about algorithm design
I'm ready to believe it but are we ready for yet another change
in paradigm within CM?
Already several issues awaits the fluent API upgrade...
You can always formulate a general request, and suggest a plan
for updating the whole library. :-)
[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 ...
Method 'up' and 'down' are the equivalent of a positive or negative
increment, respectively.
At first sight, the latter seems more usual in the context of a math
library.
Then, the "stepSize" should be restricted to positive.
Callbacks are optional. We can call increment or increment(10)
indefinitely without an exception being thrown.
Not indefinitely, only up to MAX_VALUE...
We should be able to
retrieve the number of increments left, as is included in the current
design.
We could add that, if the need arises.
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.
I don't get that. Here the main purpose is to set a hard limit
that will raise an exception (to avoid that some algo from running
forever).
Regards,
Gilles
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
