commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] UnexpectedNegativeIntegerException
Date Mon, 03 Sep 2012 20:56:29 GMT
> > [...]
> >
> > There must be something imprecise in the CM project description which I've
> > read somewhere, mentioning "state-of-the-art". I understood it as "best
> > practices in Java programming and OO design", but I must have been wrong.
> Probably what you remember reading is this on the home page:
> " All algorithms are fully documented and follow generally accepted
> best practices."

Yes, that's it.
And indeed, the first thing that came to my mind is "best [programming]
Those best practices evolve over time and vary with the language (or more
exactly, with the paradigm supported by the language).
[For an example of both and how incoherent, incomprehensible and
unmaintainable a code can be when we mix oil and water, please look at
"BOBYQAOptimizer"! And this is already after dozens of hours converting from
Fortran (goto etc.) to Java (OO).]

> We have never claimed to be anything more than a practially useful,
> open source, open-development Java mathematics library implementing
> standard algorithms with no dependencies or IP encumberance and good
> documentation.  This is consistent with how other Commons components
> describe themselves.  The key is that *usefulness*, *ease of use*
> and *approachability of the code* is more important than any one
> developer's idea of what constitutes "best coding practices" or
> "state-of-the-art" Java (whatever that means). 

None of the qualities which you cite as worthy goals are in contradiction
with what you say is less important.
In fact, quite the contrary, applying the paradigm supported by the language
improves everything else (ease of use, approachability, hence usefulness).

In our case, respecting the basic tenets of object-oriented programming
should be a top (!) priority if we hope to to build a library for the
longer term.
IMHO, we should promote Java (OO) state-of-the-art best practices when
designing the API and writing the code.

Sometimes, we can arrive to a dead-end, where we'd need to derogate to the
rules. At that point we might realize that the design was not good enough
to cater for all (new) the requirements.
If we have to maintain compatibility, and if there is really no other
choice, only then should we be allowed to break the rules.
If we can break compatibility, then the design can be evolved, based on the
new insights. Failing to do that from time to time will be the cause of the
demise of CM (as of many other programming projects).

> It seems a reasonable compromise in this case would be to provide
> the getters that Luc is asking for (making the library easier to
> use), while at the same time continuing to build out the exception
> hierarchy so that more use cases can be handled without
> programmatically unpacking exception contexts.

All I suggest is that we are aware that there is something fundamentally
wrong (in the sense of OO fundamentals) with the approach which you aptly
describe as "unpacking exception contexts".

[I think that this and other decisions will hurt the project later. But
I can understand that a pressing need might need to be solved urgently.
I did not mean to oppose adding the accessors (I even thought they existed
already!); I am arguing about the principles.]

We should also acknowledge that this change is useful only for people who
will actually _read the source code_ (in order to spot what pattern was
passed to the raised exception): the pattern is not documented (and rightly
so IMO!).
Until we have cleaned up the "LocalizedFormats" (removing all duplicates or
near duplicates), we should not be tied to keep any pattern in the API.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message