On Sun, Jan 29, 2017 at 11:15 AM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Sun, 29 Jan 2017 10:36:07 -0500, Raymond DeCampo wrote: > >> 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? >> > > I'm not sure I understand what you wrote here. > > So shouldn't we get buy-in from the commons-text team >> before we make a decision? >> > > My proposal does not imply that someone else should implement > the code. > > For example, if you feel confident that the input parsing and > output formatting classes are useful and well implemented, you > can start a discussion on this ML (with subject prefix [Text]), > to inquire about objections to moving them to [Text]. > It seems that it was informally agreed that [Text] is a somewhat > higher level component, i.e. that it can have runtime dependencies. > > 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. >> > > Certainly. > But it is easier to justify as "out of scope", rather than "we don't > care about format X". > Then if someone comes up with a good library that can handle the > "Commons Numbers" types, our incomplete code will become obsolete, > and any work put in it will have been useless. The question is: > Are there _currently_ any use-cases for it? > > If there aren't, please let's not rush to add it to the new component. > > >>> 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. >> > > I do not have enough imagination. ;-) > > Well the first use-case that comes to my mind is accepting user input from some kind of GUI and turning it into a Fraction instance. The second would be extracting Fraction values from some kind of text representation, e.g. CSV file, XML, etc. But I think we are reaching the end of the useful phase of the discussion so that said, I don't really have strong feelings on the matter. I would leave it in were it up to me but I wouldn't oppose you if you wanted to take it out.
