Re: [CLI] [DISCUSS] Help formatter extension proposal
My vote (which everyone is free to ignore) is still for HelpWriter. It's simple and intuitive, and it's consistent with the names of the methods the interface declares (e.g. writePara, writeTable). I find SemanticAppendableDecorator too verbose and I have no intuition for what it means. Peter On Mon, Sep 30, 2024, 12:31 PM Claude Warren wrote: > If we can settle on a name for the > serializer/scribe/writer/printDecorator/amenuensis thing the rest of the > code is ready. It passes all the tests, it has 100% test coverage, and it > works for what Rat is trying to do. > > > On Sat, Sep 28, 2024 at 2:08 PM Claude Warren wrote: > > > I have opened https://github.com/apache/commons-cli/pull/314 to track > the > > proposed changes > > > > On Sat, Sep 28, 2024 at 11:42 AM Claude Warren wrote: > > > >> I know some graphics programs use the term "engraver" for code that > >> creates the output of graphical representations of things (like notes, > >> staves, and resets in musical notation). Scribe seems like the textual > >> equivalent. > >> > >> If we go with the decorator approach then I think the underlying > >> interface should be SemanticAppendableDecorator. > >> > >> > >>- Semantic because it describes what to do with the semantic terms > >>like "paragraph", "header", and "list". > >>- Appendable because that is what is wraps. > >>- Decorator because that is what it does. > >> > >> > >> > >> On Sat, Sep 28, 2024 at 9:26 AM Gilles Sadowski > >> wrote: > >> > >>> Le sam. 28 sept. 2024 à 00:17, Gary Gregory a > >>> écrit : > >>> > > >>> > It's pretty unusual IMO, not like anything in the JDK for example. > >>> > >>> Agreed. > >>> > >>> > I'll see > >>> > if I can come up with something tomorrow... > >>> > >>> How about "PrintDecorator" ? > >>> > >>> Gilles > >>> > >>> >>> [...] > >>> > >>> - > >>> 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 >
Re: [CLI] [DISCUSS] Help formatter extension proposal
That sounds similar to java.io.Writer. Maybe this should be a HelpWriter?
On Wed, Sep 25, 2024, 7:11 PM Claude Warren wrote:
> Actually the Producer constructor takes an "Appendable" as an argument and
> then provides methods like
>
> printPara("Some text here")
>
> Which would output a paragraph of "Some text here"
>
> TestProducer appends "Some text here\n\n" (where \n is
> System.lineSeparator) to the appendable
> XmlProducer would append something like "Some text here" to the
> appendable.
>
> (they really are serializing the data to an output format)
>
> Claude
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
Re: [beanutils] Thoughts on PR https://github.com/apache/commons-beanutils/pull/276
I agree with Gary. If an object is exposing sensitive data in its toString() then the problem should be fixed at the source. Peter On Tue, Sep 3, 2024, 11:04 AM Gary D. Gregory wrote: > I appreciate the intent but this feels like bad solution. If a toString() > method return a password, then the security issue is in the toString() IMO. > > Gary > > On 2024/09/03 14:18:03 Melloware Inc wrote: > > I could be wrong but his whole intent of that PR was not logging a > > bean.toString() that might accidentally expose a password. That seems to > > be his entire goal. So if there is a better way to achieve that goal is > > what i think the developer was going for. > > > > On Tue, Sep 3, 2024 at 9:52 AM Gary D. Gregory > wrote: > > > > > On 2024/08/31 12:44:19 Melloware Inc wrote: > > > > I feel like this PR is a good idea. Just from a safety perspective > and > > > not > > > > accidentally logging a password. > > > > > > The PR does nothing to avoid logging passwords. It only plays games > when a > > > bean implements toString() which might have unexpected consequences. > I'm > > > not sure. > > > > > > I took another look and I'm not sure this is helpful though, and it > also > > > contains some global variable editing that will be problematic IMO. > See my > > > comments in the PR. > > > > > > Gary > > > > > > > > > > > On Mon, Aug 26, 2024 at 5:41 PM Gary D. Gregory > > > > wrote: > > > > > > > > > Hi All, > > > > > > > > > > Does anyone have thoughts on PR > > > > > https://github.com/apache/commons-beanutils/pull/276 ? > > > > > > > > > > TY, > > > > > Gary > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > -- > > > > == > > > > Melloware > > > > melloware...@gmail.com > > > > http://melloware.com > > > > == > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > -- > > == > > Melloware > > melloware...@gmail.com > > http://melloware.com > > == > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [LANG] LANG-1747: Measure the execution time of functional interfaces #1254
I think this is a useful addition, but I wonder if these new APIs are misnamed: StopWatch::test doesn't actually test, nor does StopWatch::accept consume. Instead, these all wrap lambdas in a timed version of the same type. (There's probably some lambda calculus terminology for this.) I'd propose renaming all of the functional interface-wrapping functions to use a single, overloaded name, e.g. StopWatch::timed(...) or StopWatch::withTiming(...) /peter On Fri, Aug 16, 2024, 10:50 PM Gary Gregory wrote: > Hi all, > > Please provide any feedback on > - LANG-1747: Measure the execution time of functional interfaces #1254 > - https://github.com/apache/commons-lang/pull/1254/ > TY! > Gary > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [COLLECTIONS] CartesianProductIterator
I don't know if it's been proposed before, but I think any implementation would necessarily be inefficient. I imagine such an iterator would need to produce objects of type Pair. This would lead to a lot of allocation and could create garbage collection pressure. The same functionality can be achieved with a nested for-loop (or flatMap()), much more efficiently. On Wed, Jun 26, 2024, 12:27 PM Alexey Pelykh wrote: > G'day to all! > > It seems there's no Iterator that would implement the same thing as > Python's itertools.product (quite literally a nested for loop) with some > Java stream() capabilities. > Is this intentional (as in, was considered and rejected) or a PR with such > CartesianProductIterator would be welcomed? > > Be well, > Alexey
Re: [collections] breaking changes
This could be solved if it were possible to force javac to generate bridge
methods. There's an extension which would allow that here:
https://github.com/infradna/bridge-method-injector, but I suspect it would
complicate the build process quite a bit.
On Thu, Mar 29, 2018 at 4:48 PM sebb wrote:
> The return type is part of the method signature that Java uses to find
> resolve references.
>
> Even changing from void to non-void will cause binary incompatibility.
> (Source-wise, that's fine)
>
> On 29 March 2018 at 18:20, Gary Gregory wrote:
> > Yep, that's no good. I'll revert.
> >
> > Gary
> >
> > On Thu, Mar 29, 2018 at 10:16 AM, Paul King
> > wrote:
> >
> >> I haven't looked into the IteratorUtils class at all but it's easy to
> >> show binary incompatibility when changing the return type.
> >> Compile this "library" class:
> >>
> >> import java.util.ArrayList;
> >> import java.util.List;
> >>
> >> public class Lib {
> >> List getMyList() {
> >> return new ArrayList();
> >> }
> >> }
> >>
> >> Now compile this user of the library:
> >>
> >> import java.util.List;
> >>
> >> public class Main {
> >> public static void main(String[] args) {
> >> doit(new Lib().getMyList());
> >> }
> >>
> >> private static void doit(List list) {
> >> System.out.println("list is: " + list);
> >> }
> >> }
> >>
> >>
> >> Ensure it all works:
> >>
> >> > java -cp path_to_lib Main
> >>
> >> Should output:
> >>
> >> List is: []
> >>
> >> Now change the Lib class to return ArrayList instead of List and
> >> recompile just the Lib class (i.e. importantly don't recompile Main).
> >>
> >> Now if you try:
> >>
> >> > java -cp path_to_lib Main
> >>
> >> you should see:
> >>
> >> Exception in thread "main" java.lang.NoSuchMethodError:
> >> Lib.getMyList()Ljava/util/List;
> >> at Main.main(Main.java:5)
> >>
> >> Cheers, Paul.
> >>
> >> On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory
> >> wrote:
> >> > Can you show how older code would not function. Aside from using
> >> reflection.
> >> >
> >> > Gary
> >> >
> >> > On Thu, Mar 29, 2018, 09:03 Claude Warren wrote:
> >> >
> >> >> if we are using semantic numbering would this not cause a major
> revision
> >> >> change as older code will no longer function?
> >> >>
> >> >> Claude
> >> >>
> >> >> On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory <
> garydgreg...@gmail.com>
> >> >> wrote:
> >> >>
> >> >> > Hi All:
> >> >> >
> >> >> > Updating Commons Collections' commons-parent from version 43 to 45
> >> causes
> >> >> > the build to fail due to the use of japicmp which reports:
> >> >> >
> >> >> > [ERROR] Failed to execute goal
> >> >> > org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site)
> on
> >> >> > project commons-collections4: Error generating
> >> >> > japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate
> >> report:
> >> >> > Breaking the build because there is at least one incompatibility:
> >> >> > org.apache.commons.collections4.IteratorUtils.
> >> peekingIterator(java.util.
> >> >> > Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.
> >> >> > collections4.IteratorUtils.pushbackIterator(java.util.
> >> >> > Iterator):METHOD_RETURN_TYPE_CHANGED
> >> >> > -> [Help 1]
> >> >> >
> >> >> > This is caused by:
> >> >> >
> >> >> > - [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator
> signature to
> >> >> > return PushbackIterator.
> >> >> > - [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature
> to
> >> >> > return PeekingIterator.
> >> >> >
> >> >> > Which are reasonable changes IMO.
> >> >> >
> >> >> > Does anyone object to these changes and adding exceptions to allow
> >> >> japicmp
> >> >> > to
> >> >> > not fail the build?
> >> >> >
> >> >> > Thank you,
> >> >> > Gary
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> I like: Like Like - The likeliest place on the web
> >> >>
> >> >> 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
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [text] Upper/Lower case enum
This feels like it might have been more useful pre-Java 8. Why not use a
lamda function, which would permit arbitrary string transformations?
/peter
On Thu, Feb 22, 2018, 7:42 PM Gary Gregory wrote:
> On Thu, Feb 22, 2018 at 4:27 PM, sebb wrote:
>
> > On 22 February 2018 at 23:15, Gary Gregory
> wrote:
> > > On Thu, Feb 22, 2018 at 4:11 PM, sebb wrote:
> > >
> > >> On 22 February 2018 at 22:27, Gary Gregory
> > wrote:
> > >> > Use your imagination ;-)
> > >>
> > >> What would the new code look like?
> >
> > I mean the user code before and after the enum is introduced.
> >
>
> I don't have code for the _before_ since I wrote the enum to avoid it.
>
> I have a different util class that gets called like this:
>
> HexDump(byte[] data, LetterCase letterCase, more details...)
>
> This is much clearer than using a boolean for the letter case.
>
> Gary
>
>
> >
> > >>
> > >
> > > I posted the code at the start of this thread...
> > >
> > > Gary
> > >
> > >
> > >>
> > >> How does it compare with code that does not have the enum?
> > >>
> > >> > I use it in the following contexts:
> > >> > - To pass to a hex dump method to configure where the alpha chars
> > should
> > >> be
> > >> > in lower case or upper case.
> > >> > - To configure a parameterized JUnit test class to configure the
> case
> > of
> > >> > HTTP headers and values.
> > >> > - To normalize input
> > >> >
> > >> > Gary
> > >> >
> > >> >
> > >> > On Thu, Feb 22, 2018 at 3:14 PM, Otto Fowler <
> ottobackwa...@gmail.com
> > >
> > >> > wrote:
> > >> >
> > >> >> What problem does it solve?
> > >> >>
> > >> >> On February 22, 2018 at 17:02:34, Gary Gregory (
> > garydgreg...@gmail.com)
> > >> >> wrote:
> > >> >>
> > >> >> Does anyone think this is useful and general enough to add to
> Commons
> > >> >> Text:
> > >> >>
> > >> >> /**
> > >> >> * Enumerates letter cases and converts strings.
> > >> >> *
> > >> >> * @author mailto:ggreg...@rocketsoftware.com";>Gary
> > Gregory
> > >> >> */
> > >> >> public enum LetterCase {
> > >> >> LOWER {
> > >> >> @Override
> > >> >> public String toCaseString(final String source, final Locale
> > >> >> locale) {
> > >> >> return source.toLowerCase(locale);
> > >> >> }
> > >> >>
> > >> >> },
> > >> >> UPPER {
> > >> >> @Override
> > >> >> public String toCaseString(final String source, final Locale
> > >> >> locale) {
> > >> >> return source.toUpperCase(locale);
> > >> >> }
> > >> >> };
> > >> >>
> > >> >> /**
> > >> >> * Converts from the given {@code source} string to the case
> specified
> > >> >> by this enum using the given {@code locale}.
> > >> >> *
> > >> >> * @param source
> > >> >> * the string to convert
> > >> >> * @param locale
> > >> >> * the locale to use for conversion.
> > >> >> * @return a converted string.
> > >> >> */
> > >> >> public abstract String toCaseString(String source, Locale locale);
> > >> >> }
> > >> >>
> > >> >> ?
> > >> >>
> > >> >> Thank you,
> > >> >> Gary
> > >> >>
> > >> >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > >>
> > >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
