By factory i assume you mean builder in this context To my understanding a factory can produce mutiple types of objects while a builder ony one. I got called out on that awhile ago on a different project
Should we then make all existing builders in CLI implement supplier and deprecate the current build methods in favor of get? Would this be your recommendation? On Tue 14 May 2024, 19:02 Gary Gregory, <garydgreg...@gmail.com> wrote: > Also think of the anti pattern of all Commons Components implementing their > own factory pattern with a custom interface instead of just reusing Java's > own Supplier. > > Gary > > On Tue, May 14, 2024, 1:00 PM Gary Gregory <garydgreg...@gmail.com> wrote: > > > IMO future factories should only be Suppliers. > > > > Whether to deprecate current code in favor of Suppliers is possible if > > only a bit noisy. > > > > Gary > > > > On Tue, May 14, 2024, 12:22 PM Claude Warren <cla...@xenei.com> wrote: > > > >> I have submitted a draft pull request > >> https://github.com/apache/commons-cli/pull/272 > >> > >> However, I would like to resolve the Builder/build Builder/get naming > >> issue > >> before I take it out of draft mode. > >> > >> > >> > >> On Tue, May 14, 2024 at 6:05 PM Claude Warren <cla...@xenei.com> wrote: > >> > >> > I will add some tests to show what it is doing in the various cases. > >> But > >> > I think that since we are now providing external developers with the > >> > ability to display custom information about the Option there are a > >> > couple of function that we could probably use internally and provide > to > >> the > >> > external developer. > >> > > >> > A prime example is the ability to get the string "-s" or "-s, > --longopt" > >> > or "--longopt" as an output based on weather the option has a short > >> option, > >> > long option or both defined. This is used in several places > internally, > >> > and I have had to code it for some external code I was developing. > >> > > >> > There are probably others that we can find the code base but I was > >> > thinking an "OptionUtils" or "OptionFormat" or "OptionHelper" class > that > >> > has static methods taking an Option. > >> > > >> > Are there any objections to this? > >> > > >> > > >> > On Tue, May 14, 2024 at 4:08 PM Claude Warren <cla...@xenei.com> > wrote: > >> > > >> >> Eric, I may have broken it with my implementation of the > HelpFormatter > >> >> deprecatedFormatFunc() method. > >> >> > >> >> On Tue, May 14, 2024 at 4:06 PM Claude Warren <cla...@xenei.com> > >> wrote: > >> >> > >> >>> We already have historical uses of builders in CLI (e.g. > >> >>> CommandLine.Builder) that use build() not get(). > >> >>> In addition many of the other commons packages have Builders that > are > >> >>> triggered by a "build" call. > >> >>> > >> >>> On Tue, May 14, 2024 at 3:03 PM Gary Gregory < > garydgreg...@gmail.com> > >> >>> wrote: > >> >>> > >> >>>> Hi All, > >> >>>> > >> >>>> Better documentation is always nice :-) > >> >>>> > >> >>>> I vote for Supplier/get() because it does not require the invention > >> of > >> >>>> something new that does _exactly the same thing as the code already > >> >>>> provided in the JRE_. > >> >>>> > >> >>>> Gary > >> >>>> > >> >>>> On Tue, May 14, 2024 at 8:22 AM Claude Warren <cla...@xenei.com> > >> wrote: > >> >>>> > > >> >>>> > I find a couple of issues: > >> >>>> > > >> >>>> > No documentation for the new options. (I am working on that). > >> >>>> > A weird mix of .get() and .build() methods on builders. The new > >> >>>> builders > >> >>>> > all extend Supplier<> so the get makes sense in that respect, > but I > >> >>>> don't > >> >>>> > think this is the normal nomenclature for Builders. I expect a > >> >>>> build() > >> >>>> > method. In any case we should settle on one or the other. In > case > >> >>>> it is > >> >>>> > not obvious I vote for build(). > >> >>>> > > >> >>>> > On Mon, May 13, 2024 at 11:54 AM Claude Warren <cla...@xenei.com > > > >> >>>> wrote: > >> >>>> > > >> >>>> > > Will do. > >> >>>> > > > >> >>>> > > On Sun, May 12, 2024 at 8:49 PM Gary Gregory < > >> >>>> garydgreg...@gmail.com> > >> >>>> > > wrote: > >> >>>> > > > >> >>>> > >> How does it look now? > >> >>>> > >> > >> >>>> > >> Would you check git master is OK, then I can cut a release > >> >>>> candidate > >> >>>> > >> later in the week. > >> >>>> > >> > >> >>>> > >> Gary > >> >>>> > >> > >> >>>> > >> On Sat, May 11, 2024 at 6:28 AM Claude Warren < > >> cla...@apache.org> > >> >>>> wrote: > >> >>>> > >> > > >> >>>> > >> > Also, it appears that the deprecatedHandler is only tested > on > >> >>>> the string > >> >>>> > >> > option processing. if the application retains a list of > >> Options > >> >>>> and > >> >>>> > >> passes > >> >>>> > >> > those in to be checked the deprecation check is not execute. > >> >>>> > >> > > >> >>>> > >> > On Sat, May 11, 2024 at 12:18 PM Claude Warren < > >> >>>> cla...@apache.org> > >> >>>> > >> wrote: > >> >>>> > >> > > >> >>>> > >> > > Greetings, > >> >>>> > >> > > > >> >>>> > >> > > I see that there is a deprecated option in cli 1.7.0, and > >> that > >> >>>> it has > >> >>>> > >> some > >> >>>> > >> > > nice data. But I don't see how to display the info in the > >> >>>> help. > >> >>>> > >> > > > >> >>>> > >> > > It looks like the only option is to print "[Deprecated]" > >> >>>> without any > >> >>>> > >> > > information from the deprecated info. I think the > >> HelpPrinter > >> >>>> needs a > >> >>>> > >> > > function (similar to the command line deprecatedHandler) > to > >> >>>> convert > >> >>>> > >> the > >> >>>> > >> > > object to a string that can be prefixed to the option help > >> >>>> output > >> >>>> > >> where the > >> >>>> > >> > > "[Deprecated]" is now. > >> >>>> > >> > > > >> >>>> > >> > > Does this make sense? > >> >>>> > >> > > > >> >>>> > >> > > Is there something I am overlooking that already does > this? > >> >>>> > >> > > > >> >>>> > >> > > Claude > >> >>>> > >> > > > >> >>>> > >> > > > >> >>>> > >> > > > >> >>>> > >> > >> >>>> > >> > >> >>>> > --------------------------------------------------------------------- > >> >>>> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >>>> > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> >>>> > >> > >> >>>> > >> > >> >>>> > > > >> >>>> > > -- > >> >>>> > > LinkedIn: http://www.linkedin.com/in/claudewarren > >> >>>> > > > >> >>>> > > >> >>>> > > >> >>>> > -- > >> >>>> > LinkedIn: http://www.linkedin.com/in/claudewarren > >> >>>> > >> >>>> > --------------------------------------------------------------------- > >> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >>>> For additional commands, e-mail: dev-h...@commons.apache.org > >> >>>> > >> >>>> > >> >>> > >> >>> -- > >> >>> LinkedIn: http://www.linkedin.com/in/claudewarren > >> >>> > >> >> > >> >> > >> >> -- > >> >> LinkedIn: http://www.linkedin.com/in/claudewarren > >> >> > >> > > >> > > >> > -- > >> > LinkedIn: http://www.linkedin.com/in/claudewarren > >> > > >> > >> > >> -- > >> LinkedIn: http://www.linkedin.com/in/claudewarren > >> > > >
