[Bug 62875] Area with empty cell is shifted

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62875

--- Comment #1 from gallon.fizik@gmail.com <ga...@gmail.com> ---
I've come across several similar cases recently, namely with Product and
Geomean functions. I'll post a PR soon with Product, where I change the way
MultiOperandNumericFunction.collectValue() handles non-numeric values resolved
from explicit argument/area reference/reference. It's not a MatrixFunction but
the idea and implementation of collecting evals to a double[]/double[][] array
is the same.

Instead of boolean flags (blanksAreCounted,  boolsAreCounted) I introduce a
thing I called EvalConsumer<T extends ValueEval, RECEIVER> (not the best name,
perhaps I'll think of a better one). The idea is to simplify the configuration
of such functions by introducing a set of consumers which actually perform the
handling. The base class is not a Consumer because the latter doesn't allow
throwing a checked EvaluationException. The three most common consumer flavors
are Coerce (use the value directly or try to cast), Skip and Throw. The
implementations are so simple that can well be lambdas.

That said, the collectValue() from a sheet of if instanceof else if instance of
will change to something like:
EvalConsumer consumer = resolveConsumer(ValueEval ev, boolean isViaReference);
consumer.consume(ev, accumulator);

We may go even further and maintain a [lazily populated] map <T extends
ValueEval -> EvalConsumer<T, RECEINVER> so that we don't have to resolve the
consumer once again for each argument. Or a list (actually, this is the Chain
of Responsibility pattern). Thanks for making me clarify this :)

An option to set a custom handler/hook/filter is easily implemented. In
pseudo-code, the config for MDETERM may look like:

class MDETERM extends MatrixFunction {
    MDETERM() {
      super(...);
      addHandler(BlankEval.class, (value, receiver) -> {throw new
EvaluationException(ErrorEval.VALUE_INVALID);};
    }
}


Going further, such a universal construct may later become a part of the
generic OperandResolver.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org