Hello.
> >>> [...]
> >>> In order to avoid this, what I tend to do at the moment is to define a
> >>> new class --say, BoundedPoint-- which would hold three double:s an
> >>> initial value, a lower bound and an upper bound. Then I would just
> >>> provide the method with the corresponding array of BoundedPoint,
> >>> instead of three arrays of doubles. Then no dimension mismatch can
> >>> occur, and no additional information needs be provided in the javadoc.
> >>> Of course, the price to pay is that you have to construct a few
> >>> BoundedPoint. As I said, this is what I tend to do at the moment, but
> >>> I have mixed feelings about this solution vs. passing 3 double[]. Any
> >>> thoughts about this side question?
> >>
> >> On the principle, you are right of course.
> >> But I'm not sure that we gain much by adding this layer of data
> >> encapsulation, because having a single array (instead of three) is not
> >> enough to prevent a dimensionality error: indeed, the arrays dimension must
> >> match the expected argument of the function, and this possible mismatch can
> >> only be detected later, when the function is called (within the
> >> "doOptimize"
> >> method).
> >>
> > OK, that's a fair point.
> >
> >>
> >> To be completely safe, we would have to introduce an additional method
> >> ("getDimension") in the "MultivariateFunction" interface. [But this has
> >> the drawback that it reduces the generality of this interface.]
> >>
> > I'm certainly not claiming that such a method *should* be added, but
> > may I ask why you think it reduces generality? I guess you are
> > thinking of generic multivariate functions, with unspecified number of
> > arguments (like sum(), product(), ...),
Yes.
> > but this could be handled by
> > returning eg a negative value.
That's not very object-oriented. ;-)
And it adds another check. And it is an "out-of-band" information: Users
must know that a negative value is not wrong as a dimension, which is
counter-intuitive. And it can lead to bugs (a negative value was passed
when actually it shouldn't have been).
When I see all these little annoyances, it makes me feel that there is more
to the refactoring than a quick fix like adding a "getDimension" method.
> > Again, I'm not claiming anything, I'm
> > just wondering (actually, wondering if what I did was wrong --or not
> > so good--, in a project I'm working on at work...).
>
> [...]
As Luc said, if it works for you, there is probably nothing wrong.
When you start to add code to work around your design, then it means that
refactoring may be needed.
> >> [...]
> >> That said, I agree that it would be nicer to have a completely uniform and
> >> integrated set of interfaces. The current design is already quite a rework
> >> of the previous state of affairs (see versions 2.1 and 2.2) with much of
> >> the
> >> inconsistency and code duplication corrected. However, similarly to other
> >> design issues raised during the last months, it is not clear that the
> >> obvious solution at this point will lead to a clear improvement in the
> >> overall design. I mean that the code might in fact need a more thorough
> >> refactoring, not some patch here and there. But that work would be for the
> >> next++ major release. :-)
> >>
> > I'm too new to this project to make any statement... We'll talk about
> > that in a few years...
>
> No, nobody is too new. Everybody can express their concerns and propose
> something different.
Right; the problem is rather that sometimes people are too old to accept
change... ;-}
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
