Hi.
> > [...]
> >>
> >> What I clearly don't like in our setting is the complexity of the
> >> hierarchy with the generics. I have the same reluctance with the solvers
> >> hierarchy, and was directly hit by both when I needed to had a new
> >> function type for differentials (see
> >> <http://mail-archives.apache.org/mod_mbox/commons-dev/201209.mbox/%3C5050B2A3.2050007%40free.fr%3E>
> >> and
> >> <http://mail-archives.apache.org/mod_mbox/commons-dev/201208.mbox/%3C50374A8F.6040806%40spaceroots.org%3E>).
> >> So I would be very happy if we could simplify our hierarchy here and
> >> mainly remove the top level generics (like BaseOptimizer<PAIR> and
> >> BaseMultivariateOptimizer<FUNC extends MultivariateFunction> extends
> >> BaseOptimizer<PointValuePair> and simply have a set of parallel
> >> non-generics interfaces with fixed signatures, one for each type we
> >> need.
To be clear, you are referring to the "user" interfaces which I enumerated
below?
> >> These top level interfaces don't add much value and completely
> >> prevent to implement several of them in one class, due to type erasuer
> >> (something we did not notice when we designed this). Their javadoc even
> >> states "This interface is mainly intended to enforce the internal
> >> coherence of Commons-Math. Users of the API are advised to base their
> >> code on the following interfaces:".
> >
> > I am responsible for the current hierarchy design but it was based on an
> > earlier one, not much simpler, but with much more duplicated code.
> > At refactoring the identified goal was to merge all the codes that could be.
> >
> > The point is that different algorithm have generated different based on
> > several points:
> > * Univariate vs multivariate function
> > * Scalar vs sector function
> > * "optimize" return type: "PointValuePair" vs "PoinVectorValuePair"
> >
> > The generics were used to "summarize" all the existing flavours (and push
> > common features one level up). [Boilerplate code in "Abstract..." classes.]
> >
> >> A coworker of mine asked me today which interface he should use in the
> >> signature of a method he was writing and which should take an optimizer
> >> as an argument. He was puzzled by our hierarchy and did not understand
> >> which level he should use in his declaration. Even knowing the
> >> internals, the history, the various implementations and their
> >> differences, it took me almost an hour to answer his question. So our
> >> hierarchy really needs to be streamlined.
> >
> > The user interfaces didn't change I think, and do not refer to generics.
>
> Yes, this is exactly my point. These interfaces are not for users, they
> are for [math] developers.
The interfaces with a generic parameter ("T" or "FUNC") are not for users;
those without generic parameters (but which extends a generic with a
specific type in place of "T" ot "FUNC") are for users (those enumerated
below). I that what you mean?
> However, they do confuse users who see them
> and even reading the javadoc don't understand their purpose. They also
> prevent an implementation to support two interfaces at a time and hence
> to be smoothly upgraded as we improve our basic users interfaces.
I have mixed feelings. Indeed it is a pity that generics do not really
create new types; it is type erasure that got in your way, not the generics.
But I agree that in the end, it's not necessary to keep interfaces just for
internal use: We should be able to avoid redundancy and keep code
duplication just by respecting a policy. Of course, the refactoring was
done _because_ the last statement was not true. ;-)
>
> > They are
> > * DifferentiableMultivariateVectorOptimizer
> > * DifferentiableMultivariateOptimizer
> > * DifferentiableMultivariateMultiStartOptimizer
> > * DifferentiableMultivariateVectorMultiStartOptimizer
> > * MultivariateMultiStartOptimizer
> > * MultivariateOptimizer
> > * UnivariateOptimizer
> >
> > [Anything whose names start with "Base..." or "Abstract..." is neither for
> > users nor for application developers but for developers of concrete
> > algorithms
> > for CM.]
> >
> >
> > What do you propose? Wat is streamlining a library?
>
> I propose to remove the generics from pure interfaces (this would have
> to wait for 4.0, of course), and hence reduce the number of layers at
> least by one, and if possible by more than one.
All simplifications are welcome :-).
I think that my proposal (cf. original subject of this thread) is also
about simplication of the API (for easier usage):
1. Construct an optimizer.
2. Call the "optimize" method.
[No intermediate calls to specific methods that are not in the general API.]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
