Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.help > #1280 > unrolled thread

Enum basics

Back to article view | Back to comp.lang.java.help

Contents

  Enum basics Roedy Green <see_website@mindprod.com.invalid> - 2011-11-04 15:11 -0700
    Re: Enum basics "John B. Matthews" <nospam@nospam.invalid> - 2011-11-04 20:44 -0400
      Re: Enum basics Lew <lewbloch@gmail.com> - 2011-11-04 20:27 -0700
        Re: Enum basics "John B. Matthews" <nospam@nospam.invalid> - 2011-11-05 02:23 -0400
          Re: Enum basics Lew <lewbloch@gmail.com> - 2011-11-05 00:51 -0700
        Re: Enum basics Roedy Green <see_website@mindprod.com.invalid> - 2011-11-05 04:12 -0700
          Re: Enum basics Lew <lewbloch@gmail.com> - 2011-11-05 09:15 -0700
            Re: Enum basics Patricia Shanahan <pats@acm.org> - 2011-11-05 14:06 -0700
              Re: Enum basics Lew <lewbloch@gmail.com> - 2011-11-05 15:54 -0700
              Re: Enum basics Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-05 20:43 -0300
              Re: Enum basics markspace <-@.> - 2011-11-05 19:55 -0700
              Re: Enum basics Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-11-05 22:10 -0500
    Re: Enum basics Roedy Green <see_website@mindprod.com.invalid> - 2011-11-05 04:18 -0700

#1280 — Enum basics

Are enums supposed to support static variables? static methods?

If the enum is nested in another class, are enum methods supposed to
be able to access the containing classes instance variables and
methods?

I believe the answer is "no" to all these questions, but I don't want
to lead people astray in my essay on enums.

You have to communicate with the enum via the initial constructor, or
by parms on enum methods.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Capitalism has spurred the competition that makes CPUs faster and 
faster each year, but the focus on money makes software manufacturers 
do some peculiar things like deliberately leaving bugs and deficiencies
in the software so they can soak the customers for upgrades later.
Whether software is easy to use, or never loses data, when the company
has a near monopoly, is almost irrelevant to profits, and therefore 
ignored. The manufacturer focuses on cheap gimicks like dancing paper 
clips to dazzle naive first-time buyers. The needs of existing 
experienced users are almost irrelevant. I see software rental as the 
best remedy.

[toc] | [next] | [standalone]

#1283

In article <3bo8b7dd306f6pj50v2jk3t9704n1c0cjp@4ax.com>,
 Roedy Green <see_website@mindprod.com.invalid> wrote:

> Are enums supposed to support static variables? static methods?
> 
> If the enum is nested in another class, are enum methods supposed to
> be able to access the containing classes instance variables and
> methods?
> 
> I believe the answer is "no" to all these questions, but I don't want
> to lead people astray in my essay on enums.

I believe the answer is yes to all three, as suggested here:

<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.9>
<http://stackoverflow.com/questions/1973018>
<http://groups.google.com/group/comp.lang.java.help/msg/6c3a3d7a27be6331>

As a practical matter, I've never had cause to access enclosing class 
members from an enum.

> You have to communicate with the enum via the initial constructor, or
> by parms on enum methods.

I found it helpful to recall that "An enum type has no instances other 
than those defined by its enum constants."

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

#1284

John B. Matthews wrote:
> Roedy Green wrote:
>> Are enums supposed to support static variables? static methods?
>> 
>> If the enum is nested in another class, are enum methods supposed to
>> be able to access the containing classes instance variables and
>> methods?
>> 
>> I believe the answer is "no" to all these questions, but I don't want
>> to lead people astray in my essay on enums.

Nope.

> I believe the answer is yes to all three, as suggested here:

Nope.

And there are only two.  The question of static fields or static methods is the same question.

> <http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.9>
> <http://stackoverflow.com/questions/1973018>
> <http://groups.google.com/group/comp.lang.java.help/msg/6c3a3d7a27be6331>
> 
> As a practical matter, I've never had cause to access enclosing class 
> members from an enum.
> 
> > You have to communicate with the enum via the initial constructor, or
> > by parms on enum methods.
> 
> I found it helpful to recall that "An enum type has no instances other 
> than those defined by its enum constants."

Why *not* read the JLS?  This is exactly the sort of question for which the JLS is the quickest, and yes, the clearest place to find such answers, as well as, by definition, the authority.  You already know the JLS exists, you already know it answers these questions, and there's even a whole freaking section, §8.9, obscurely entitled "Enums", wherein it states:

"Nested enum types are implicitly static. It is permissable [sic] to explicitly declare a nested enum type to be static.
"Discussion
"This implies that it is impossible to define a local (§14.3) enum, or to define an enum in an inner class (§8.1.3)."

Boom.  Second question answered.  No, an enum cannot access an enclosing class's instance members.  What's the big mystery?

As for the first question, well, enum instances are themselves static members of the enum, so it's obvious on the face of it that enums can support static members.  More subtly, we know that enums are actually classes, and as such can have both static and instance members.

Also, we know that enums inherit from Enum<E>, and that class itself has heritable static members, so we know that enums have static members that are not the enum constants.

When in doubt, why not run a simple example up in your favorite development environment?

public enum Foo
{
  /** Foo. */
  FOO,;

  public static final String NON_FOO = "Not foo.";
}

Oh, and wouldn't you know it?  The aforementioned obscurely-entitled section of the JLS even provides us this example:

enum Color {
  RED, GREEN, BLUE;
  static final Map<String,Color> colorMap = 
     new HashMap<String,Color>();
  static {
    for (Color c : Color.values())
     colorMap.put(c.toString(), c);
  }
} 

Not only a static member, but a static initializer block!  Woohoo!

So the answer is "yes" to static members and "no" to enclosing-class instance members.  Ain't the JLS a freaking gold-mine of information?  Answers in a heartbeat!

-- 
Lew
You don't have to be a language lawyer to understand the cited passages, either.  Just a programmer.

[toc] | [prev] | [next] | [standalone]

#1285

In article 
<21054701.30.1320463633638.JavaMail.geo-discussion-forums@prog16>,
 Lew <lewbloch@gmail.com> wrote:

> John B. Matthews wrote:
> > Roedy Green wrote:
> >> Are enums supposed to support static variables? static methods?
> >> 
> >> If the enum is nested in another class, are enum methods supposed 
> >> to be able to access the containing classes instance variables and 
> >> methods?
> >> 
> >> I believe the answer is "no" to all these questions, but I don't 
> >> want to lead people astray in my essay on enums.
> 
> Nope.
> 
> > I believe the answer is yes to all three, as suggested here:
> 
> Nope.
>
> And there are only two.  The question of static fields or static 
> methods is the same question.

Ah, I counted three: 1) static variables, 2) static methods and 3) 
access to members of an enclosing class. You saw 1) and 2) as a single 
question regarding static members
 
> > <http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.9>
> > <http://stackoverflow.com/questions/1973018>
> > <http://groups.google.com/group/comp.lang.java.help/msg/6c3a3d7a27be6331>
> > 
> > As a practical matter, I've never had cause to access enclosing 
> > class members from an enum.
> > 
> > > You have to communicate with the enum via the initial 
> > > constructor, or by parms on enum methods.
> > 
> > I found it helpful to recall that "An enum type has no instances 
> > other than those defined by its enum constants."
> 
> Why *not* read the JLS?  This is exactly the sort of question for 
> which the JLS is the quickest, and yes, the clearest place to find 
> such answers, as well as, by definition, the authority.  You already 
> know the JLS exists, you already know it answers these questions, and 
> there's even a whole freaking section, §8.9, obscurely entitled 
> "Enums", wherein it states:

I agree completely; as a language citizen, the JLS is the best way to 
for me decide if I've erred or found a compiler bug. It's usually the 
former. Of course, I always appreciate your clarifying the finer points.

> "Nested enum types are implicitly static. It is permissable [sic] to 
> explicitly declare a nested enum type to be static. "Discussion "This 
> implies that it is impossible to define a local (§14.3) enum, or to 
> define an enum in an inner class (§8.1.3)."
> 
> Boom.  Second question answered.  No, an enum cannot access an 
> enclosing class's instance members.  What's the big mystery?

D'oh, I misread the question, thinking of _static_ members of the 
enclosing class; Roedy clearly said _instance_.

> As for the first question, well, enum instances are themselves static 
> members of the enum, so it's obvious on the face of it that enums can 
> support static members.  More subtly, we know that enums are actually 
> classes, and as such can have both static and instance members.

> [helpful clarification elided]

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

#1286

John B. Matthews wrote:
> Lew wrote:

...
>> Boom.  Second question answered.  No, an enum cannot access an 
>> enclosing class's instance members.  What's the big mystery?
> 
> D'oh, I misread the question, thinking of _static_ members of the 
> enclosing class; Roedy clearly said _instance_.

Yeah, I had to reread the post a couple of times to make sure I had the sense of it right way 'round.

As for my post upthread, the "you" there was the generalized "you, the reader", not you the poster.  I was writing a post, not an email, so what I said was not meant for anyone to take personally but in the spirit of an essay.

Just in case, you know.

As for the distinction between "nested" (i.e., static) and "inner" (instance) classes, I have been much more sensitive to the fine distinction after encountering the interesting edge case of an inner class that inherits from its containing class and accesses the latter's private members.


package eegee;
public class Outer
{
  private String foo()
  {
    return "Outer.foo() ";
  }

  protected String bar()
  {
    return "Outer.bar() ";
  }

  class Inner extends Outer
  {
    public String foo()
    {
      return "Inner.foo() ";
    }

    public String bar()
    {
      return "Inner.bar() ";
    }
  }

  public static void main(String [] args)
  {
    Outer encloser = new Outer();
    Inner inner = encloser.new Inner();
    Outer outer = inner;
    System.out.println("encloser: " + encloser.foo() + encloser.bar());
    System.out.println("   outer: " + outer.foo() + outer.bar());
    System.out.println("   inner: " + inner.foo() + inner.bar());
  }
}

Of course, @Override helps here.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#1287

On Fri, 4 Nov 2011 20:27:13 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>Why *not* read the JLS?

see http://mindprod.com/jgloss/jls.html for why it is not sufficient.

But happily we have a resource, you, a person who has infinite
confidence in their ability to divine the intentions of the JLS
authors, and who is nearly always correct.

The problem is the cost of submitting a question to the Oracle, not
the company, is to accept a verbal  beating for not possessing the
same skill.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Capitalism has spurred the competition that makes CPUs faster and 
faster each year, but the focus on money makes software manufacturers 
do some peculiar things like deliberately leaving bugs and deficiencies
in the software so they can soak the customers for upgrades later.
Whether software is easy to use, or never loses data, when the company
has a near monopoly, is almost irrelevant to profits, and therefore 
ignored. The manufacturer focuses on cheap gimicks like dancing paper 
clips to dazzle naive first-time buyers. The needs of existing 
experienced users are almost irrelevant. I see software rental as the 
best remedy.

[toc] | [prev] | [next] | [standalone]

#1291

Roedy Green wrote:
> Lew wrote, quoted or indirectly quoted someone who said :
>> Why *not* read the JLS?
> 
> see http://mindprod.com/jgloss/jls.html for why it is not sufficient.
> 
> But happily we have a resource, you, a person who has infinite
> confidence in their ability to divine the intentions of the JLS
> authors, and who is nearly always correct.
> 
> The problem is the cost of submitting a question to the Oracle, not
> the company, is to accept a verbal  beating for not possessing the
> same skill.

Apparently you chose to ignore my post:
>> As for my post upthread, the "you" there was the generalized "you, the 
>> reader", not you the poster.  I was writing a post, not an email, so what 
>> I said was not meant for anyone to take personally but in the spirit of an >> essay. 
>> 
>> Just in case, you know. 

in favor of disparaging the helpful advice.  We all know that you like to discourage newbies from going to the source with B.S. like you put in the referenced link.  Were the cited passages and code examples on this matter really so very hard to understand, Roedy?

You do Java programmers, especially nedwer ones, a tremendous disservice with your strange campaign against one of the most fundamental tools, and the most authoritative one, to understand the language, the Java Language Specification.  Your irrational and damaging campaign against the JLS needs to stop.  I would think with all your self-promotion as a champion of newbies and purveyor of programming pedagogy that you would be joining me in the effort to make the JLS available, explicable and useful to everyone. 

But, no.

Shame on you, Roedy.

Contrary to the crap you put forward, Roedy, you don't have to be a "language lawyer" to understand the cited passages, either.  Just a programmer. 

Are you a programmer?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#1292

On 11/5/2011 9:15 AM, Lew wrote:
...
> Contrary to the crap you put forward, Roedy, you don't have to be a
> "language lawyer" to understand the cited passages, either.  Just a
> programmer.

Lew's claim seems to be that any programmer can read the JLS. Roedy's
claim seems to be that JLS reading is a specialized skill, distinct
from, and in addition to, general programming skill.

This is actually an interesting question. To me, the JLS seems the
clearest description of Java I have found, and is my go-to document when
I want to know anything about the core language, as distinct from the
libraries.

However, I had studied the theory of formal grammars and compiler
construction, worked on compilers, and read several other language
specifications before Java was invented. I may be a "language lawyer".

I'm interpreting "a programmer" as someone who can program, without
requiring any other skill. This question could easily become circular if
inability to read the JLS were treated as evidence of not being a
programmer.

So, here is a question for people who can program in Java, or can
program in at least one other language and are learning Java:

Can you understand the JLS?

Patricia

[toc] | [prev] | [next] | [standalone]

#1293

Patricia Shanahan wrote:
> Lew wrote:
> ...
>> Contrary to the crap you put forward, Roedy, you don't have to be a
>> "language lawyer" to understand the cited passages, either.  Just a
>> programmer.
> 
> Lew's claim seems to be that any programmer can read the JLS. Roedy's

Actually, my claim is that any Java programmer *should* read the JLS.

Like any other programming skill, understanding the specification requires some practice and effort to learn.  It's an effort that must be made.

> claim seems to be that JLS reading is a specialized skill, distinct
> from, and in addition to, general programming skill.

To be a programmer requires more than being able to slavishly copy a for-loop into a method.  It is an engineering skill pulling in a panoply of foundational skills such as being able to reason from incomplete specifications, knowing how to architect cooperating layers, ramping up independently on libraries and technologies that one needs, understanding algorithmic behaviors such as runtime asymptotes, and many, many more skills that go into the complex art of computer programming.

> This is actually an interesting question. To me, the JLS seems the
> clearest description of Java I have found, and is my go-to document when
> I want to know anything about the core language, as distinct from the
> libraries.
> 
> However, I had studied the theory of formal grammars and compiler
> construction, worked on compilers, and read several other language
> specifications before Java was invented. I may be a "language lawyer".
> 
> I'm interpreting "a programmer" as someone who can program, without
> requiring any other skill. This question could easily become circular if
> inability to read the JLS were treated as evidence of not being a
> programmer.

It is incomplete as you present it, and itself is circular already, and trivially so.  You define a programmer as "someone who can program" without defining what that skill is.

My working definition of "the skill of computer programming" is pragmatic, based on what it takes to create software effectively, in a time constraint, with attention to elimination of defects.

Like "the skill of dancing", the skill of programming encompasses a limitless landscape of related activities that one masters in varying degrees at different times.  The point I make is that for a Java programmer, to have a prejudice against understanding the very specification of the language is disempowering at best, and stupid at least.  For someone claiming to represent the interests of those learning Java, either for the first time or ongoingly, to put forward the notion that one should avoid learning how to read the spec is evil.

> So, here is a question for people who can program in Java, or can
> program in at least one other language and are learning Java:
> 
> Can you understand the JLS?

If the answer is, "No", then it's time to start learning how to.  

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#1294

On 11-11-05 06:06 PM, Patricia Shanahan wrote:
> On 11/5/2011 9:15 AM, Lew wrote:
> ...
>> Contrary to the crap you put forward, Roedy, you don't have to be a
>> "language lawyer" to understand the cited passages, either.  Just a
>> programmer.
> 
> Lew's claim seems to be that any programmer can read the JLS. Roedy's
> claim seems to be that JLS reading is a specialized skill, distinct
> from, and in addition to, general programming skill.
> 
> This is actually an interesting question. To me, the JLS seems the
> clearest description of Java I have found, and is my go-to document when
> I want to know anything about the core language, as distinct from the
> libraries.
> 
> However, I had studied the theory of formal grammars and compiler
> construction, worked on compilers, and read several other language
> specifications before Java was invented. I may be a "language lawyer".
> 
> I'm interpreting "a programmer" as someone who can program, without
> requiring any other skill. This question could easily become circular if
> inability to read the JLS were treated as evidence of not being a
> programmer.
> 
> So, here is a question for people who can program in Java, or can
> program in at least one other language and are learning Java:
> 
> Can you understand the JLS?
> 
> Patricia

I can understand the JLS. It's just not that the JLS is the clearest
description, it's that it is a *clear* description.

In theory (and in practice) a lot of programmers can get by without
language specs, just like a lot get by without reading APIs. They are
hurting themselves, but they get by. Maybe by knowing what the good
blogs and articles are. However, a truly professional programmer must be
aware of what the relevant documentation is, and be prepared to use it.
It saves time, and is more reliable.

I think we can all agree that some specifications are mediocre or
atrocious. A number of W3C specs come to mind. In other words, some
specs are hard to understand, and/or contain errors or ambiguities.
Anyone could be forgiven for confessing problems with these. But most
specs, including the JLS, are adequate or better, and IMHO if you can't
understand these then you're not a programmer. You're a hacker.

AHS
-- 
You should know the problem before you try to solve it.
Example: When my son was three he cried about a problem with his hand. I
kissed it several times and asked him about the problem. He peed on his
hand.
-- Radia Perlman, inventor of spanning tree protocol

[toc] | [prev] | [next] | [standalone]

#1295

On 11/5/2011 2:06 PM, Patricia Shanahan wrote:
> To me, the JLS seems the
> clearest description of Java I have found, and is my go-to document when
> I want to know anything about the core language, as distinct from the
> libraries.
>


For the most part I agree.  The JLS is even unusually clear for a 
specification.  I find it easy to read.

However, that's for the most part.  There are sections I still struggle 
to read correctly, even when I understand the answer already.  For 
example, plowing through the Final Field Semantics part of the JLS 
Memory Model, there's a part where the spec formally defines the 
Dereference Chain and the Memory Chain for final field semantics.  I 
think I understand what they are saying, because I know the answer from 
reading Java Concurrency in Practice, but I'm not sure I could correctly 
derive the answers in JCiP from the description they give.  (However the 
description before that part is pretty clear on the effects of final 
fields.)

Note that this really don't apply to enums, which I think are much more 
clearly written.  Although I admit I didn't try reading that part of the 
JLS again before replying here.

So overall, yes, folks should try to read the JLS, or learn how as Lew 
suggests.  But given that the JLS might not always be 100% clear, it's 
also OK to ask questions.  The overriding concern in this thread seems 
to be that Roedy didn't make an attempt to read or understand the JLS, 
he just expected CLJH to do his (home-) work for him.

[toc] | [prev] | [next] | [standalone]

#1296

On 11/5/2011 4:06 PM, Patricia Shanahan wrote:
> Lew's claim seems to be that any programmer can read the JLS. Roedy's
> claim seems to be that JLS reading is a specialized skill, distinct
> from, and in addition to, general programming skill.

 From my perspective (one I've inherited from others), the critical 
skill needed in programming is not mathematics or logic but actually 
plain old reading and writing skills. In that vein, general programming 
skill amounts to being able comprehend and communicate the various 
requirements of programs, which includes being able to comprehend a 
formal document of underlying semantics of the language (like the JLS). 
In other words, to have general programming skill is, in part, to be 
able to read a well-written language standard [1].

> I'm interpreting "a programmer" as someone who can program, without
> requiring any other skill. This question could easily become circular if
> inability to read the JLS were treated as evidence of not being a
> programmer.

I will admit that my definition of general programming skill leaves open 
the possibility (indeed, probability) that there exist large numbers of 
programmers who do not have general programming skill. I therefore 
object to the use of the term "a programmer" in favor of either "a 
competent programmer," "a skilled programmer," or "a good programmer."

> Can you understand the JLS?

I too would consider myself a language lawyer, but Java is the first 
programming language I truly learned and also the first language where I 
discovered the formal specification, so I started reading and 
understanding it before I became a language lawyer.

That said, I can definitely see a few places in the language where good 
technical writing was eschewed in favor of mathematical detail and 
precision (the rules for generics, particularly generic type inference, 
and the memory model are the best examples). Perhaps that is 
unavoidable; on the other hand, the fact that the number of examples and 
side discussions in these sections drop dramatically is probably a sign 
that the authors didn't try hard enough to make this more easily accessible.

[1] Not all language standards are well-written. However, of all the 
standards I have read, I have found the JLS (and associated standard API 
documentation) to be among the clearest examples of well-written 
specifications.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#1288

On Fri, 04 Nov 2011 15:11:45 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

>Are enums supposed to support static variables? static methods?

I wrote an SSCCE to sort this out.  See
http://mindprod.com/jgloss/enum.html#VARIABLESCOPE

The bottom line is: enums can have static variables shared between all
enum constants and instance variables. Nested enums can access the
static final constants and static variables of the enclosing class,
but not its instance variables. static and instance methods behave
similarly. Implicitly, a nested enum is a nested static class, so this
is the expected behaviour.  
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Capitalism has spurred the competition that makes CPUs faster and 
faster each year, but the focus on money makes software manufacturers 
do some peculiar things like deliberately leaving bugs and deficiencies
in the software so they can soak the customers for upgrades later.
Whether software is easy to use, or never loses data, when the company
has a near monopoly, is almost irrelevant to profits, and therefore 
ignored. The manufacturer focuses on cheap gimicks like dancing paper 
clips to dazzle naive first-time buyers. The needs of existing 
experienced users are almost irrelevant. I see software rental as the 
best remedy.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.help

csiph-web