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