Le 05/10/2012 16:56, Gilles Sadowski a écrit :
> 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?
Yes. The user interfaces should be kept.
>
>>>> 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?
Yes, it is what I 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.
Yes, but unfortunately the Java language was designed this way, so we
have to cope with it. Also I don't blame anybody (neither the language
designers for choosing type erasure, nor you for setting up the generics
interface, nor any other developers for not seeing this problem at that
time.
>
> 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.]
Yes, and I finally agreed with this (see my comment on MATH-874). Let's
try it.
Luc
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
