Replaced all "enum" singletons with "[static] final class"es in both master
and release-2.x.

On Wed, Nov 18, 2020 at 2:04 PM Gary Gregory <[email protected]> wrote:

> Hi Volkan,
>
> I think the strength of the feelings in my argument was more of a
> reflection on my frustration of my lack of involvement in this new valuable
> module. There are many FOSS projects I care about and only so many hours in
> a day. I am glad that you are open to my views, regardless of the outcome
> we choose.
>
> In general I would say we want 100% binary compatibility for the 2 API
> modules. For other modules we don't want to make life harder than it has to
> be for folks but my personal view is that this case falls into the category
> where we can do whatever we want.
>
> Gary
>
> Gary
>
> On Wed, Nov 18, 2020, 03:15 Volkan Yazıcı <[email protected]> wrote:
>
> > Thanks for your sincere feedback Gary, really appreciated.
> >
> > Given none of us is really strongly opinionated about this, except Gary,
> I
> > am okay to follow his suggestion. This brings up the following question:
> > Shall I replace all enum singletons (in JTL module) with "final classes
> > with a private ctor"? If so, would it break the binary compatibility? If
> it
> > would, given JTL is a pretty new module and probably doesn't have any
> > wide-spread usage of its classes by users, is it a big deal?
> >
> > BTW, I am really happy this (un?)fortunate occasion triggered another
> > committer to review the JTL code base. Feels like a win for me. ;P
> >
> > On Wed, Nov 18, 2020 at 12:28 AM Gary Gregory <[email protected]>
> > wrote:
> >
> > > [Please take this constructively despite my string words]
> > >
> > > Arg. As much as I love Effective Java and admire Joshua Bloch, this one
> > > feels like a brain fart, and Block even concedes this pattern "may
> feel a
> > > bit unnatural", no kidding. This is an ENUM, but it does NOT enumerate
> > > ANYTHING. It is only used as a hack to avoid defining a private ctor.
> The
> > > falls for me in the same category as defining constants in interfaces
> > when
> > > interfaces should be used to define contracts.
> > >
> > > To make things worse, this enum does not even follow the pattern
> > documented
> > > in Effective Java because it does not define an INSTANCE enum value!
> > >
> > > For me, this definitely violates the principle of least surprise :-(
> > >
> > > Sorry to pile on... but also: Why is this type even public?
> > >
> > > I suppose I only have myself to blame for not reviewing the original
> > commit
> > > ;-) but I am reviewing now ;-)
> > >
> > > Gary
> > >
> > >
> > >
> > > On Tue, Nov 17, 2020 at 3:59 PM Carter Kozak <[email protected]>
> wrote:
> > >
> > > > I'm a big fan fan of enum singletons. This case looks like an enum
> with
> > > no
> > > > values for utility methods to avoid a private ctor, I haven't used
> > enums
> > > > this way myself. I think the trade-off is between avoiding having to
> > > write
> > > > a private constructor to prevent extension, and the downside of enum
> > > static
> > > > methods e.g. Uris.values(), Uris.valueOf(String),
> > > > Uris.valueOf(Class,String) which could be argued violate the
> principle
> > of
> > > > least astonishment. I don't have much of an opinion on enum utility
> > > methods.
> > > >
> > > > On Tue, Nov 17, 2020, at 15:48, Volkan Yazıcı wrote:
> > > > > I use enums for singletons, which is the recommended way to create
> > > > > singletons in Effective Java by Joshua Bloch. Given I have used it
> in
> > > > some
> > > > > other places as well and heard no complaints so far, I did not
> > convert
> > > > them
> > > > > to a final class with a private ctor. Should I?
> > > > >
> > > > > On Tue, Nov 17, 2020 at 9:25 PM Gary Gregory <
> [email protected]
> > >
> > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Why is this an enum and not a class?
> > > > > >
> > > > > > Gary
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to