From: www on
Roedy Green wrote:
> On Wed, 14 Jul 2010 14:42:57 -0400, www <www(a)nospam.com> wrote, quoted
> or indirectly quoted someone who said :
>
>> private ABC_ENUM(final String techName, final boolean boolValue)
>> {
>> _techName = techName;
>> _boolValue = boolValue;
>> }
>
> the usual convention would look like this:
>
> ABC ( final String techName , final boolean boolValue )
> {
> this.techName = techName;
> this.boolValue = boolValue;
> }
>
> This ties the variables together more tightly.
>

Thank you. Just curious, if the constructor is private is sufficient,
why bother to make it default?

I do see many enum tutorials use default accessible constructor. I don't
understand that.
From: ClassCastException on
On Fri, 16 Jul 2010 10:40:16 -0400, www wrote:

> Roedy Green wrote:
>> On Wed, 14 Jul 2010 14:42:57 -0400, www <www(a)nospam.com> wrote, quoted
>> or indirectly quoted someone who said :
>>
>>> private ABC_ENUM(final String techName, final boolean boolValue) {
>>> _techName = techName;
>>> _boolValue = boolValue;
>>> }
>>
>> the usual convention would look like this:
>>
>> ABC ( final String techName , final boolean boolValue )
>> {
>> this.techName = techName;
>> this.boolValue = boolValue;
>> }
>>
>> This ties the variables together more tightly.
>>
>>
> Thank you. Just curious, if the constructor is private is sufficient,
> why bother to make it default?
>
> I do see many enum tutorials use default accessible constructor. I don't
> understand that.

Maybe because the constructor may as well be private anyway -- it won't
work if you try to call it anywhere but in a constructor in one of its
own enum constants. Otherwise you could, say, do a "new
javax.swing.SortOrder()" or whatever and get an instance of SortOrder
that wasn't any of ASCENDING, DESCENDING, or UNSORTED and then pass it to
the SortKey constructor ...
From: Lew on
www wrote:
> Just curious, if the [emum] constructor is private is sufficient,
> why bother to make it default [access]?
>
> I do see many enum tutorials use default accessible constructor. I don't
> understand that
>

Why bother to make it private?

Not only is it more typing (and you know I don't regard that as much
of an excuse), but it requires some compilation magic for enum
instances' inner-class bodies to get at an enclosing private
constructor, not needed when they access an enclosing package-private
constructor.

It's ultimately a question of taste, like whether to include 'public'
in interface method declarations except that there is a subtle
semantic difference between the 'enum' constructor access patterns.

--
Lew
From: Andreas Leitgeb on
Lew <lew(a)lewscanon.com> wrote:
> www wrote:
>> Just curious, if the [emum] constructor is private is sufficient,
>> why bother to make it default [access]?
>> I do see many enum tutorials use default accessible constructor. I don't
>> understand that
> Not only is it more typing (and you know I don't regard that as much
> of an excuse), but it requires some compilation magic for enum
> instances' inner-class bodies to get at an enclosing private
> constructor, not needed when they access an enclosing package-private
> constructor.

What would an inner-class body do with an outer enum's constructor?

From: Lew on
www wrote:
>>> Just curious, if the [emum] constructor is private is sufficient,
>>> why bother to make it default [access]?
>>> I do see many enum tutorials use default accessible constructor. I don't
>>> understand that
>

Lew wrote:
>> Not only is it more typing (and you know I don't regard that as much
>> of an excuse), but it requires some compilation magic for enum
>> instances' inner-class bodies to get at an enclosing private
>> constructor, not needed when they access an enclosing package-private
>> constructor.
>

Andreas Leitgeb wrote:
> What would an [enum instance's] inner-class body do with an outer enum's constructor?
>

Use it to generate its own implicit constructor, of course. They're
just like any other anonymous inner class that way.

--
Lew