I have to admit that i am partial to build but in reviewing gang of four and various java build patterns i find that there are a number of terminal methods.
Gary is, I now believe, correct; that the builder should implement Supplier. On Tue 14 May 2024, 19:28 Claude Warren, <cla...@xenei.com> wrote: > 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 >> >> >> > >> >
