Hi,
I realize I'm a little late to the party here, so if I'm asking or suggesting
things that are naive just let me know straight up, and I'll try to educate
myself better. I will say that I really enjoy reading these threads because I
learn a great deal from them.
As a user of commons math I think it would be great if a each exception mapped to a
"One of a kind problem". So instead of having a NegativeIntegerException,
which is generic and could be used in a lot of places, have
SuperDuperOptimizerNegativeIntegerException, which is only thrown in one place.
Is this possible?
Cheers,
- Ole
On 09/03/2012 03:56 PM, Gilles Sadowski wrote:
[...]
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]
practices".
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.
Regards,
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
