At one point i suggested a set of helper functions for Option. I think that it would really help before this change goes out. With it we can reasonably change the BiFunction to a simple function taking an Option and returning a String.
I will code this up tomorrow. Claude On Wed 15 May 2024, 09:14 Claude Warren, <cla...@xenei.com> wrote: > I opened CLI-333 to address the Build production method issue. > > On Tue, May 14, 2024 at 10:25 PM Gary Gregory <garydgreg...@gmail.com> > wrote: > >> Sounds good to me! Thank you for talking it out. GoF reference appreciated >> 👏 😉 >> >> Looking forward to a PR, >> Gary >> >> On Tue, May 14, 2024, 1:47 PM Claude Warren <cla...@xenei.com> wrote: >> >> > 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 >> > >> >> >> > >> > >> > >> >> > > >> > >> > > > -- > LinkedIn: http://www.linkedin.com/in/claudewarren >
