On Sat, Jan 28, 2017 at 7:00 PM, Gilles <gil...@harfang.homelinux.org> wrote:
> Hi. > > On Sat, 28 Jan 2017 14:38:21 -0500, Raymond DeCampo wrote: > >> [...] >>> >>> Now, for the contents of the "fraction" module. >>> >>> (1) >>> My main current concern is the formatting-related classes; as for >>> "complex", I think that >>> 1. formatting (and I/O) is out of scope, and >>> 2. the implementation were problematic in CM already. >>> Hence, I'd prefer to drop support altogether.[1] >>> >>> >>> I see your point of view, but allow me to play devil's advocate. It >> seems >> natural to create the formatter for a new object, in particular a number >> type, close to the type itself. Making new objects and expecting another >> project to implement the formatting seems like what economists call an >> externality. I suppose it really depends how everyone maintaining text >> would feel about it. I am somewhat concerned about how the release cycle >> would work, in particular for the initial released, where text would have >> to wait for a release of numbers before including the formatting and then >> users would not have formatting until the next release of text. >> >> That said if the people maintaining text agree I have no objection. >> > > [Text] is also a new component. It is not unthinkable that its scope > can encompass flexible formatting of such things as "fractions". > At the risk of raising a sore subject, wasn't the expectations of third parties that someone else maintain code for them part of the impetus for the current effort? So shouldn't we get buy-in from the commons-text team before we make a decision? > As suggested, someone having a clear idea of what would be the use > cases for formatting fraction, complex, and the likes, can create a > new "commons-text-math-formatting" module (that would depend on the > necessary modules from [Numbers]). > From my experience with them, the formatting class from [Math] are > not worth keeping. > A lot of other codes should IMHO be given higher priority. > My point is that, generally, people using "fraction" can do with the > constructors (to input data) and the accessors (to read result). > Moreover, developers of "fraction" usually would not want to spend > inordinate amounts of time to satisfy new formatting requests (that > tend to translate into hundreds of lines of code, cf. CM). > The existence of some formats shouldn't result in an obligation to support whatever formats are requested. > > The formatting code itself is not part of the concept, and so IMO > effectively out of scope. > There is no more sense to output "ugly" ASCII than there would be > to generate any other output formats that would be more suited to > represent mathematical concept (e.g. LaTeX). > > For logging and debugging purpose, "toString" should be quite fine. > I imagine that the greater value is in the parsing portion of the format classes, not the output portion. Thanks, Ray > > Regards, > Gilles > > >> (2) >>> Another concern is what to do with the "XxxField" classes. >>> >>> >> Do we have any idea if the user base uses these classes? It's no problem >> to continue to maintain them (at least from my point of view) but I am >> having difficulty imagining the use case. >> >> >> >>> (3) >>> All "@since" tags must be removed. >>> >>> (4) >>> Right now, I think that we should not advertize specific exceptions. >>> I.e. they should have at most "package" visibility, or maybe even >>> better: private inner class. >>> The Javadoc "@throws" should mention the JDK's parent class. >>> This is a departure from what was done in CM, where the design was >>> trying to satisfy mixed requirements, never shown (IMO to be really >>> necessary for a supposedly "low-level" library). >>> >>> >> That suits me fine. >> >> >> My stance is that whenever an exception is thrown from an application, >>> there is a programming error that must be solved by looking at the >>> code (to find the faulty call or bug in the library). >>> >>> Regards, >> >>> Gilles >>> >>> [1] There could be a "math-module" in "Commons Text" that would do >>> such things, with the support of more advanced text manipulation >>> classes. >>> >>> >>> >>>> >>>> On Sat, Jan 28, 2017 at 8:36 AM, Gilles <gil...@harfang.homelinux.org> >>>> wrote: >>>> >>>> Hi Ray. >>>> >>>>> >>>>> On Sat, 28 Jan 2017 12:44:27 -0000, raydeca...@apache.org wrote: >>>>> >>>>> Add maven module for fractions package from commons-math >>>>> >>>>>> Resolves pull request #4 >>>>>> >>>>>> >>>>>> Whenever possible, we aim at small commits (unless they are all of >>>>> the same kind, and it is obvious what is being done repeatedly). >>>>> >>>>> In particular, independent codes should be added incrementally, to >>>>> allow for easier review. >>>>> For example, modifications to "pom.xml", addition of "ArithmeticUtils", >>>>> "Fraction" and "BigFraction", etc. >>>>> >>>>> Please note that you worked on an outdated branch. >>>>> [Please read the guidelines in "doc/development".] >>>>> Can you fix that (using "rebase" I guess) before we discuss the >>>>> contents of the commit? >>>>> >>>>> Also to allow easy review: the commit message should refer to the >>>>> JIRA issue identifier). >>>>> >>>>> >>>>> Thanks, >>>>> Gilles >>>>> >>>>> >>>>> >>>>> [...] >>>>> >>>>>> >>>>>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
