--------------------------------------------------
From: "Phil Steitz" <phil.ste...@gmail.com>
Sent: Friday, July 23, 2010 5:42 PM
To: "Commons Developers List" <dev@commons.apache.org>
Subject: Re: clirr for MATH-389
Gilles Sadowski wrote:
Intentional but still a mistake IMO ;-) as it's part of the interface
whereas the prime use is to allow to define a default constructor so
that
the user does *not* have to refer to the value.
When using the default constructor, the user can always obtain the
default
value with "getMaxIterations()".
No, the user can get this value only once the instance has already
been
built, not before calling the constructor.
Of course. I didn't say otherwise.
When does the user need to know this value before calling the
constructor?
Mainly displaying it in a graphical user interface, as an hint for the
user to choose either this default or something else if he want to.
Unless I'm mistaken, the meaning of "iteration" is algorithm-dependent,
and
the "maximum" will depend on the problem and the requested accuracy, so
how
could CM know what is a "good" default? As far as I can tell, the value
(100) was picked out of thin air. For the number of evaluations, the
default
is MAX_VALUE (which makes more sense, in some sense ;-); and note that
this
one is not defined as a public static variable!
Certainly, the (graphical interface) program has more information (which
problem it is solving and which optimization algorithm it is going to
call
to do so) to make the right default choice.
In summary, this variable pollutes the CM API for no reason.
How useful is a default value anyway?
Last 3 items: The field still exists but in a superclass. The
problem would
have been prevented if those fields were "private" instead of
"protected".
I suggest that access to those fields is also changed to "private"
(this
breaks compatibility just the same) and I'll add accessors to be used
by
derived classes for accessing them. OK?
I'm on the fence on this.
What can you do with a "protected" field that you can't with the object
returned by an accessor?
[I even think that we should go towards immutability for those
fields...]
Yes, of course, but when I say I'm on the fence it is rather because it
introduces another incompatibility. How about deprecating them for now
and changing them to private (and perhaps final) in 3.0 ?
I've deprecated them.
So, what does that mean with respect to committing the changes into
the
trunk?
There does not seem to be any major problem, so you can commit your
changes.
Wow, that's unexpected good news. It's a relief that backward
compatibility
isn't that stringent a requirement :-)
It is a stringent requirement. But it seemed to me that the changes
were
not that important.
Fine then. I don't think they are but...
Did I miss something ?
... How would I know? Is there a policy that "clirr" cannot report
"ERROR"?
If not, then how do you decide what is important and what isn't?
It is a matter of feeling and experience. It is highly subjective and
this discussion is a perfect example of this. We can see you are ready
to change almost anything anytime, Phil doesn't want some changes to be
introduced at dot releases, and I am somewhere in between.
We are a community, and it is important we exchange our views here.
I've already suggested that we should try and assess the real impact of
the changes so that we can compare the drawbacks of each approach. I.e.
how
many people/projects are out there that would really be annoyed by a
recompilation at each dot release.
We should adhere to Commons standards. The standards are clear:
http://commons.apache.org/releases/versioning.html
Clirr ERRORs generally call out standards exceptions for a .x release.
I have no problem using natural numbers more quickly. We have
plenty! Why not just start working 3.0 in trunk. We can create a
2.x branch so we can cut a 2.2 if some really bad bugs show up
before we get 3.0 out.
We all agree that the [math] API needs work. If we cut more frequent
major releases, we can evolve the API. Lets do that.
+1 on creating a 2.2 branch and concentrating [math] on 3.0.
Phil
[...]
Maybe that the "MATH_2_0" branch contains outdated things...
Does it work on your machine?
I didn't try. However, I'm not sure clirr is useful on a major release
as it is at these releases that we allow ourselves to introduce great
changes.
But I was interested in seeing if similarly incompatible changes were
introduced in 2.1 (hence I need to "mvn install" 2.0).
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
