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 >> >
