strange recursivion with enumerated types - how is this possible?

Discussion in 'Java' started by rfractal30, Feb 21, 2005.

  1. rfractal30

    rfractal30 Guest

    Hi

    I was looking at 'enumerated types'in a tutorial and I came across some
    strange recursive situations with I couldn't understand.

    I can see the point of enumerated types as it limits the ways in which
    an object can be instanciated. Take the code below. It would not be
    possible to create an object like this:

    monthes mymonth = new monthes("fred");

    Obviously that does not work, because the constructor is private. Only
    if I were creating an instance of monthes from within that class can I
    do that. So I have enumerated types to create instances of monthes, for
    example:

    monthes mymonth = monthes.AUGUST;

    This is fine, but it occured to me that this could lead to a weird kind
    of recursion. I tested it and my suspicions turned out to be correct.
    It was therefor possible to create code such as this:

    System.out.println(mymonth.JANUARY.FEBUARY.MARCH.APRIL.NOVEMER.SEPTEMBER.JANUARY.JULY.DECEMBER.MAY.FEBUARY.getMonth());

    Crazy!!! no? I really can't understand how this is possible (but I
    tested it and it really is) How does this work? Why does the program
    not crash due to infinite recursion. I'm confused.


    //____________________________________________________
    public class monthes {


    static final monthes JANUARY = new monthes ("January");
    static final monthes FEBUARY = new monthes ("Febuary");
    static final monthes MARCH = new monthes ("March");
    static final monthes APRIL = new monthes ("April");
    static final monthes MAY = new monthes ("May");
    static final monthes JUNE = new monthes ("June");
    static final monthes JULY = new monthes ("July");
    static final monthes AUGUST = new monthes ("August");
    static final monthes SEPTEMBER = new monthes ("September");
    static final monthes OCTOBER = new monthes ("October");
    static final monthes NOVEMBER = new monthes ("November");
    static final monthes DECEMBER = new monthes ("December");

    private String month;
    private int numDays;

    private monthes(String inmonth) {


    if (inmonth.equals("January") || inmonth.equals("March") ||
    inmonth.equals("May") || inmonth.equals("July") ||
    inmonth.equals("August") || inmonth.equals("October") ||
    inmonth.equals("December")) {
    numDays = 31;
    }
    if (inmonth.equals("April") || inmonth.equals("June") ||
    inmonth.equals("September") || inmonth.equals("November")) {
    numDays = 30;
    }

    if (inmonth.equals("Febuary")){
    numDays = 28;
    }

    month = inmonth;
    }

    public String getMonth() {
    return(month);
    }
    public int getNumDays() {
    return(numDays);
    }
    }

    }


    public class TestMonthes {


    public static void main(String[] args) {



    monthes mymonth = monthes.AUGUST;


    System.out.println(mymonth.JANUARY.FEBUARY.MARCH.APRIL.NOVEMER.SEPTEMBER.JANUARY.JULY.DECEMBER.MAY.FEBUARY.getMonth());

    }

    }
    //____________________________________________________

    Thanks for any advice.

    Michael
    rfractal30, Feb 21, 2005
    #1
    1. Advertising

  2. rfractal30

    rfractal30 Guest

    Re: strange recursion with enumerated types - how is this possible?

    rfractal30 wrote:
    > Hi
    >
    > I was looking at 'enumerated types'in a tutorial and I came across

    some
    > strange recursive situations with I couldn't understand.
    >
    > I can see the point of enumerated types as it limits the ways in

    which
    > an object can be instanciated. Take the code below. It would not be
    > possible to create an object like this:
    >
    > monthes mymonth = new monthes("fred");
    >
    > Obviously that does not work, because the constructor is private.

    Only
    > if I were creating an instance of monthes from within that class can

    I
    > do that. So I have enumerated types to create instances of monthes,

    for
    > example:
    >
    > monthes mymonth = monthes.AUGUST;
    >
    > This is fine, but it occured to me that this could lead to a weird

    kind
    > of recursion. I tested it and my suspicions turned out to be correct.
    > It was therefor possible to create code such as this:
    >
    >

    System.out.println(mymonth.JANUARY.FEBUARY.MARCH.APRIL.NOVEMER.SEPTEMBER.JANUARY.JULY.DECEMBER.MAY.FEBUARY.getMonth());
    >
    > Crazy!!! no? I really can't understand how this is possible (but I
    > tested it and it really is) How does this work? Why does the program
    > not crash due to infinite recursion. I'm confused.
    >
    >
    > //____________________________________________________
    > public class monthes {
    >
    >
    > static final monthes JANUARY = new monthes ("January");
    > static final monthes FEBUARY = new monthes ("Febuary");
    > static final monthes MARCH = new monthes ("March");
    > static final monthes APRIL = new monthes ("April");
    > static final monthes MAY = new monthes ("May");
    > static final monthes JUNE = new monthes ("June");
    > static final monthes JULY = new monthes ("July");
    > static final monthes AUGUST = new monthes ("August");
    > static final monthes SEPTEMBER = new monthes ("September");
    > static final monthes OCTOBER = new monthes ("October");
    > static final monthes NOVEMBER = new monthes ("November");
    > static final monthes DECEMBER = new monthes ("December");
    >
    > private String month;
    > private int numDays;
    >
    > private monthes(String inmonth) {
    >
    >
    > if (inmonth.equals("January") || inmonth.equals("March") ||
    > inmonth.equals("May") || inmonth.equals("July") ||
    > inmonth.equals("August") || inmonth.equals("October") ||
    > inmonth.equals("December")) {
    > numDays = 31;
    > }
    > if (inmonth.equals("April") || inmonth.equals("June") ||
    > inmonth.equals("September") || inmonth.equals("November")) {
    > numDays = 30;
    > }
    >
    > if (inmonth.equals("Febuary")){
    > numDays = 28;
    > }
    >
    > month = inmonth;
    > }
    >
    > public String getMonth() {
    > return(month);
    > }
    > public int getNumDays() {
    > return(numDays);
    > }
    > }
    >
    > }
    >
    >
    > public class TestMonthes {
    >
    >
    > public static void main(String[] args) {
    >
    >
    >
    > monthes mymonth = monthes.AUGUST;
    >
    >
    >

    System.out.println(mymonth.JANUARY.FEBUARY.MARCH.APRIL.NOVEMER.SEPTEMBER.JANUARY.JULY.DECEMBER.MAY.FEBUARY.getMonth());
    >
    > }
    >
    > }
    > //____________________________________________________
    >
    > Thanks for any advice.
    >
    > Michael


    Silly typo. Sorry :)
    rfractal30, Feb 21, 2005
    #2
    1. Advertising

  3. Re: strange recursion with enumerated types - how is this possible?

    This is an excellent example of how stupid Java's syntax is!
    whoever heard of a monthe being a member of another monthe?
    sanjay manohar, Feb 22, 2005
    #3
  4. Re: strange recursion with enumerated types - how is this possible?

    sanjay manohar wrote:

    > This is an excellent example of how stupid Java's syntax is!
    > whoever heard of a monthe being a member of another monthe?


    It isn't. The example exhibits the ability in Java to refer to a class
    (static) variable or method by means of an expression of the
    corresponding type. It is widely regarded as poor style to make use of
    this capability, and some go so far as to consider it a misfeature of
    the language. The main reason for that is that it is deceptive and
    confusing: observe your own apparent misapprehension of the example,
    just for starters.

    If the months actually were members of each other, by the way, that
    wouldn't be a syntax issue. It would be a question of the design of the
    new Typesafe Enum feature.

    --
    John Bollinger
    John C. Bollinger, Feb 22, 2005
    #4
  5. rfractal30

    Chris Uppal Guest

    Anthony Borla wrote:

    > * This usage does not represent an example of enumerated
    > types. Java did not [until the latest version] sport such
    > types. This usage represents a convention that was
    > adopted to mimic this facility in Java, one that could
    > be criticised for being inefficient [i.e. needed several
    > object instances], [...]


    I'm sure you (Anthony) know this, but I think your phrasing could be misleading
    to others. The new "official" enumerated types in Java are syntactic sugar for
    the old convention for implementing them. I.e. the costs, benefits[*], and
    underlying semantics are identical. The difference is that the language-level
    solution can be more thorough, and is known to the compiler, so that it can
    conveniently "do the right thing" when it sees a switch statement for
    instance.

    ([*] mostly; there's the unwarranted -- foolish, in my book -- restriction of
    specifying behaviour for the enum objects.)

    -- chris
    Chris Uppal, Feb 23, 2005
    #5
  6. "Chris Uppal" <-THIS.org> wrote in message
    news:421c751f$1$38042$...
    > Anthony Borla wrote:
    >
    > > * This usage does not represent an example of enumerated
    > > types. Java did not [until the latest version] sport such
    > > types. This usage represents a convention that was
    > > adopted to mimic this facility in Java, one that could
    > > be criticised for being inefficient [i.e. needed several
    > > object instances], [...]

    >
    > I'm sure you (Anthony) know this, but I think your phrasing could
    > be misleading to others. The new "official" enumerated types in
    > Java are syntactic sugar for the old convention for implementing
    > them. I.e. the costs, benefits[*], and underlying semantics are
    > identical. The difference is that the language-level solution can
    > be more thorough, and is known to the compiler, so that it can
    > conveniently "do the right thing" when it sees a switch statement for
    > instance.
    >
    > ([*] mostly; there's the unwarranted -- foolish, in my book --
    > restriction of specifying behaviour for the enum objects.)
    >


    In truth I haven't had a chance to thoroughly explore the ins and outs of
    1.5 [haven't even looked at generics - I still have C++ template-related
    nightmares !], so I wasn't aware of the implementation issues you mentioned.
    I may have been assuming more than I should have.

    Thank you for pointing out those things, Chris. I'd much rather be corrected
    now than inadvertantly spread not-quite-correct information in future posts.

    Cheers,

    Anthony Borla
    Anthony Borla, Feb 23, 2005
    #6
  7. rfractal30

    rfractal30 Guest


    >
    > I hope this helps.
    >



    Yes it helps greatly! Thankyou :)
    rfractal30, Feb 25, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David R. Throop
    Replies:
    0
    Views:
    413
    David R. Throop
    May 6, 2005
  2. Replies:
    8
    Views:
    448
    Fhulu Lidzhade
    Jan 23, 2006
  3. Kevin Neilson

    Assigning Values to Enumerated Types

    Kevin Neilson, May 7, 2008, in forum: VHDL
    Replies:
    9
    Views:
    584
    Kevin Neilson
    May 9, 2008
  4. Immortal Nephi
    Replies:
    4
    Views:
    401
    Öö Tiib
    Aug 24, 2010
  5. KevinSimonson

    Using Enumerated Types as Array Indexes

    KevinSimonson, Aug 16, 2011, in forum: Java
    Replies:
    51
    Views:
    1,913
    Andreas Leitgeb
    Aug 20, 2011
Loading...

Share This Page