> > [...] > > > > 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
