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
