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 >
