The only other thing I can think of is to drop some of the retrieval patterns. We have getOption() with String, char, Option, OptionGroup as arguments and then that duplicated across getParsedOption, getOptions, and getParsedOptions. I think we can limit that to Option and Group arguments.
But otherwise I don't see a need to go to 2.x yet. On Sat, Nov 16, 2024 at 7:07 PM Gary Gregory <garydgreg...@gmail.com> wrote: > Hi Claude, > > I think we should first release the next version of 1.x and see it > propagated. Let's make sure the downstream users are as happy as we can > gauge, at least within the ecosystem we can monitor and influence. > > To ensure a smooth transition, let's deprecate the code that makes Option > mutable now with @deprecated comments as to what to expect in the future. > > Are there other classes we can or would want to make immutable? > > My impression from your message and my add-on above is that we could easily > get to a point where all that would happen in a 2.0 is the removal of > deprecated code. If that is indeed the case, then I feel we can hold off on > a 2.0 until we truly need to break binary compatibility for something more > than the removal of cruft, unless there really is a ton of it. > > TY! > Gary > > > > On Tue, Nov 12, 2024 at 6:57 PM Claude Warren <cla...@apache.org> wrote: > > > @Gary Gregory <garydgreg...@gmail.com> I see that there was a desire to > > create a V2 with an immutable Option and several other changes. > > > > I think that CLI V1 is stable now in terms of functionality and (as noted > > in the latest pull request, over specified). If there is interest in > > moving this forward I would gladly spend some time on it. > > > > I would start by restarting with the V1 code and remove the deprecated > > bits, make the Option immutable, and reduce the number of methods in the > > CommandLine class. > > > > Let me know if you would like me to proceed along these lines. > > > > Claude > > > -- LinkedIn: http://www.linkedin.com/in/claudewarren
