On Tue, Jan 11, 2022 at 9:48 AM Gilles Sadowski <gillese...@gmail.com>
wrote:
> Hello.
>
> Le mar. 11 janv. 2022 à 15:22, Gary Gregory <garydgreg...@gmail.com> a
> écrit :
> >
> > Hello Gilles and Happy New Year,
>
> Thanks. Best wishes to you, and to all contributors and reviewers.
>
> >
> > We have most input streams, output streams, readers, and writers in
> Commons
> > IO that already convert null Charset names and null Charset to the
> platform
> > default through convenience APIs; but we do not do this consistently
> > everywhere, and not for CharsetEncoder and CharsetDecoder.
> >
> > I aim to normalize this behavior to be more consistent. See the commits
> > since this one.
>
> I do not have the overall picture of what is required for "consistency".
> However, does the public API allow a "null" argument passed from
> user code being silently turned into a non-null default value, thus
> potentially hiding a programming error?
The convenience allows for default behavior to kick in for call sites
without having to jump through hoops when some input is unspecified (null)
or you want a way to say "give me the default behavior" by passing a null
or an actual default object. For example:
Foo foo = some Foo or null;
The convenient: new Something(foo);
The not convenient #1: return foo == null ? new Something(Foo.default())
: new Someting(foo);
The not convenient #2: return foo == null ? new Something() : new
Someting(foo);
The not convenient #3: new Something(foo == null ? Foo.default() : foo);
Rinse and repeat for many call sites.
HTH,
Gary
>
> >
> > I find it much simple to maintain, document, and explain the code base
> with
> > these new methods.
>
> If it is for internal consistency (of Commons IO), shouldn't such methods
> (and utility classes) be defined in an "internal" package (or be private)?
>
> >
> > Of course, you are most welcome to keep writing ternary expressions in
> your
> > call sites ;-)
>
> Depending on the answer to the first question above, the issue I'd see
> is that user code, instead of raising NPE consistently, could behave
> differently on different platforms (due to different defaults).
>
> Regards,
> Gilles
>
> >
> > Gary
> >
> > On Tue, Jan 11, 2022 at 8:41 AM Gilles Sadowski <gillese...@gmail.com>
> > [...]
> > > > +
> > > > +public class CharsetEncoders {
> > > > +
> > > > + /**
> > > > + * Returns the given non-null CharsetEncoder or a new default
> > > CharsetEncoder.
> > > > + *
> > > > + * @param charsetEncoder The CharsetEncoder to test.
> > > > + * @return the given non-null CharsetEncoder or a new default
> > > CharsetEncoder.
> > > > + * @since 2.12.0
> > > > + */
> > > > + public static CharsetEncoder toCharsetEncoder(CharsetEncoder
> > > charsetEncoder) {
> > > > + return charsetEncoder != null ? charsetEncoder :
> > > Charset.defaultCharset().newEncoder();
> > > > + }
> > >
> > > What's the use-case for such a function?
> > >
> > > void userFunction(CharsetEncoder charsetEncoder) { /* ... */ }
> > >
> > > Not using Commons IO:
> > > ---CUT---
> > > userFunction(csEnc == null ? Charset.defaultCharset().newEncoder() :
> > > csEnc);
> > > ---CUT---
> > > vs using Commons IO:
> > > ---CUT---
> > > userFunction(CharsetEncoders.toCharsetEncoder(csEnc));
> > > ---CUT---
> > >
> > > IMO, the former call is clearer (self-documenting) and safer (explicit
> > > request
> > > for a default).
> > >
> > > > [...]
> > >
> > > Gilles
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
