Hello. > >> > >>>+ * Precomputed literal arrays are provided in this class to speed up load > >>>+ * time. > >> > >>This is an implementation detail, subject to change in the (hopefully > >>not-so-distant) future. > > > >Disagree.
Why? I'm only stating a fact: Code is subject to change. > >>I would certainly not advertize it in the Javadoc. > > > >I agree here. > > I have advertised it as we did introduce some comments about start > up time some months ago, after a first Jira issue about this. > > Please go ahead fixing these comments so they are most useful to users. > > > > >I would also not advertise the ability to change to on the fly > >computation, as I think this facility should be removed. > > It's not really on the fly, Gilles set it up as a compile-time option. > > > > >There is quite a lot of code that relates only to the computation. > >The code should be kept, but in a separate class (may need to add some > >package protected methods to provide access). > > > >I don't think minimising the class source file size is nearly as > >important as the startup time. > > > >However, there are things that can be done to make the source file > >easier to read. > > > >Moving the startup code into a separate class would reduce the size of > >the class somewhat. > >The private classes holding preset arrays can be moved to the end of > >the class, and entries can be packaged several per line to shorten the > >file. > > This seems fine to me. Maybe the tables are necessary, maybe not; there is no conclusive evidence yet or, at least, it is not publicly available. Or we don't have rules (or I don't know them) that would readily provide an answer based on the benchmark results currently available. Does someone care about having a way to objectively establish whether a change is an improvement or not? Last night I've spent a long time to try to convince myself that ~5000 computations would slow down startup significantly. The results I've obtained show otherwise. Maybe I did the benchmark wrong. But anyways, I think that the minimum, before making a change which not everyone agrees on, it to prove that it is needed. [Then, as I'm questioning the usefulness of precomputing (in particular, factorials), a change is committed as if this issue did not need any consensus.] Thus, please explain why the same policy is not applied to everyone. I don't want to be too annoying here but I don't appreciate that the burden of the proof is always on me, whether I'm making a change, or whether someone else is making it and I'm questioning its validity. [But maybe there are some special rules I've yet to discover...] Thank for your attention, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
