Page 1 of 2 12 LastLast
Results 1 to 20 of 31
  1. #1
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Question Changing a property of an enum

    Hi,

    I am wondering if you can shed some light on this issue.

    Enums can have properties (fields, variables) and you can change them runtime. I wonder if this is a good idea.

    Example class:

    Java Code:
    public class EnumTest {
    	public enum MyTest {
    		GOOD(1), BAD(2);
    		
    		int value;
    		
    		MyTest(int v) {
    			this.value = v;
    		}
    		
    		public void set(int v) {
    			this.value = v;
    		}
    	}
    	
    	public static void main(String[] args) {
    		MyTest.GOOD.set(3);
    		System.out.println("MyTest.GOOD.value is now " + MyTest.GOOD.value);
    	}
    }
    The output of this thing is "3". So I can take an enum and change its value. But it seems to me like this is application-wide. For one, I never instantiated MyTest, so the enum class is like a static inner class and every value (instance) only exists once throughout the entire application?

    It seems like a bad idea to use it as for instance changable flags. Suppose you have some state machine and you offer an enum class as a way of introducing or inserting a set of flags.

    Java Code:
    enum Flag {
        ALT(false), CTRL(false);
    
        boolean value;
        
        Flag(boolean v) {
            value = v;
        }
        
        public void set(boolean v) {
            value = v;
        }
    }
    Now you can easily create an EnumSet based on the class:

    Java Code:
    EnumSet set = EnumSet.allOf(Flag.class);
    And then you can do funky things with it. But if you start changing the value of the flags, well, I'm not sure if it went well if you instantiated the class you are doing another time.

    The test case is easily expanded to become:

    Java Code:
    public class EnumTest {
    	public enum MyTest {
    		GOOD(1), BAD(2);
    		
    		int value;
    		
    		MyTest(int v) {
    			this.value = v;
    		}
    		
    		public void set(int v) {
    			this.value = v;
    		}
    	}
    	
    	public void show() {
    		System.out.println("And from this instantiated method: " + MyTest.GOOD.value);
    	}
    	
    	public static void main(String[] args) {
    		MyTest.GOOD.set(3);
    		System.out.println("MyTest.GOOD.value is now " + MyTest.GOOD.value);
    		
    		new EnumTest().show();
    		MyTest.GOOD.set(4);
    		new EnumTest().show();
    	}
    }
    And the output is:

    Java Code:
    MyTest.GOOD.value is now 3
    And from this instantiated method: 3
    And from this instantiated method: 4
    Me thinks I have to find another way to do this stuff. Using static variables as state holders doesn't seem to be a good idea.

  2. #2
    jim829 is offline Senior Member
    Join Date
    Jan 2013
    Location
    Northern Virginia, United States
    Posts
    6,226
    Rep Power
    14

    Default Re: Changing a property of an enum

    You don't have to provide a set method. And the more immutable a class is the better. So I would still prefer enums instead of static bit masks to pass arguments. If you have a method that takes an enum of type Flag you don't have to validate it (like you would an int value). You can pass them separately as individual arguments or in an EnumSet.

    Regards,
    Jim
    The JavaTM Tutorials | SSCCE | Java Naming Conventions
    Poor planning on your part does not constitute an emergency on my part

  3. #3
    DarrylBurke's Avatar
    DarrylBurke is offline Forum Police
    Join Date
    Sep 2008
    Location
    Madgaon, Goa, India
    Posts
    12,059
    Rep Power
    26

    Default Re: Changing a property of an enum

    Quote Originally Posted by Xen View Post
    I never instantiated MyTest, so the enum class is like a static inner class and every value (instance) only exists once throughout the entire application?
    Correct, except that an enum needn't be an inner class. The enum constants are static final instances of the enum class.

    Are you aware that enums implicitly extend java.lang.Enum<E extends Enum<E>> ?

    db
    If you're forever cleaning cobwebs, it's time to get rid of the spiders.

  4. #4
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: Changing a property of an enum

    Quote Originally Posted by jim829 View Post
    You don't have to provide a set method. And the more immutable a class is the better. So I would still prefer enums instead of static bit masks to pass arguments. If you have a method that takes an enum of type Flag you don't have to validate it (like you would an int value). You can pass them separately as individual arguments or in an EnumSet.

    Regards,
    Jim
    I was more meaning that you cannot use the enum to have additional, changable parameters because they are static constants and their fields/properties are also static variables.

    I generally prefer Enums over primitive types. But Enums can be very very very very slow, if you are really with a time-essential operation (such a brute force techniques, path searching, anything that is computationally expensive) then the enum provides for VAST overhead. I don't remember exactly, but I remember enum operations using hidden Maps or Hashtables or something like that. When you decompile an Enum using program, you will find how utterly expensive they are. If you are seriously running the same routine for millions of times, you cannot use enums.

    Quote Originally Posted by DarrylBurke View Post
    Correct, except that an enum needn't be an inner class. The enum constants are static final instances of the enum class.

    Are you aware that enums implicitly extend java.lang.Enum<E extends Enum<E>> ?

    db
    Yeah. I don't care much about the generics signature :p, but I know they are enums -- I use java.lang.Enum all the time currently. Because I am using parameterized types, in the sense that I have some class that I pass along.

    Sometimes I am willing to go all the way and be able to use e.g. both Enums and Strings, but mostly at this point I go the easy route, and offer my code the choice of using any type of Enum, and I provide type safety (not through generics) but by asserting that the parameters I get are of the same type.

    E.g.

    Java Code:
    public void someMethod(Enum param) {
        assert paramClass.equals(param.getClass()) : "Something is going wrong, badly :P";
    }
    Where paramClass is e.g. the result of "State.class" where State is some enum.

    Now that we are talking about Enums (enums) I have one gripe.

    Normally when using static final ints, for example, you can easily include these constants in your class, e.g./i.e. the default for such usage is that these constants become part of the class itself:

    Java Code:
    public static final int SCORE = 100;
    ...
    ThisClass.SCORE;
    What I mean is that the constants are directly accessible on the level of that enclosing class. But with Enums, generally you can only access them through the Enum itself.

    Now, you can import static Enum types / constants if they are declared in another class/file. But you cannot import static anything that is in your present file.

    As far as I'm concerned.

    So that leaves you with the option of e.g. making a dedicated "Constants" class/file that contains several enums, that you can then easily import static into whatever you want (which I have already done on one occassion).

    Is there any other way, perhaps? Now I have ugly code like:

    Java Code:
    events.put(Event.Type.ENTRY, new EnumMap(stateClass));
    ^^^ I am using an EnumMap here (they are said to be really fast) to index a collection of other maps. I.e. the equivalent of:

    Java Code:
    Map[] events = new Map[3];
    events[Event.Type.ENTRY.ordinal()] = new EnumMap(stateClass);
    ========
    I'm kinda annoyed by the fact that I use so few arrays. Particularly because without generics, using Collection classes can become or becomes very arduous. Arrays are simple and fast and are often suitable, but I find myself gravitating towards Sets and Maps and Lists all the time. Moreover because I use a lot of enums, and the indexing I just did ("events[Event.Type.ENTRY.ordinal()]") is also not exactly prettiest.

    I just think type safety is not that important. I rarely make type mistakes and when I do it is a simple matter of a ClassCastException --- of course generics also provide for some level of documentation, which is nice, and I write generics documentation as well ;-).

    So basically what I hate is that without generics you constantly have to cast objects, and with generics you constantly have to read and write ugly. ;-).

    And Enums sit in between and advocate more Collection classes over arrays.

  5. #5
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: Changing a property of an enum

    What I mean is that you cannot use an enum directly as an index to an array.

    Java Code:
    maps[Event.EXIT]
    versus
    Java Code:
    maps.get(Event.Type.EXIT)
    which, without generics, becomes
    Java Code:
    Map m = (Map)maps.get(Event.Type.EXIT);
    as opposed to

    Java Code:
    Map m = maps[Event.Type.EXIT];
    You can see what's nicer.

    ===========
    But with generics, it might become

    Java Code:
    Map<Event.Type, Map> map = .....
    which is also not the prettiest, I guess. So it is choosing between two evils, so to speak.
    Last edited by Xen; 08-04-2015 at 06:41 PM.

  6. #6
    jim829 is offline Senior Member
    Join Date
    Jan 2013
    Location
    Northern Virginia, United States
    Posts
    6,226
    Rep Power
    14

    Default Re: Changing a property of an enum

    So many things to address. I guess I don't think that generics are that bad. And enums were not designed to be used to index arrays. If you want to do that, then retrieve a value from a constructor. But I would stay away from ordinal() because it is reliant on enum field position (use a constructor instead). And from what I have read in SO, enums are not that expensive to use.

    I think that any short term inconvenience of using the generic or enum syntax saves much more on long term maintainability of programs. But it all boils down to using or not using the optional features. If you don't like them, don't use them (and suffer the consequences). Or just choose a different language; there are plenty out there.

    Regards,
    Jim
    The JavaTM Tutorials | SSCCE | Java Naming Conventions
    Poor planning on your part does not constitute an emergency on my part

  7. #7
    DarrylBurke's Avatar
    DarrylBurke is offline Forum Police
    Join Date
    Sep 2008
    Location
    Madgaon, Goa, India
    Posts
    12,059
    Rep Power
    26

    Default Re: Changing a property of an enum

    Quote Originally Posted by Xen View Post
    I was more meaning that you cannot use the enum to have additional, changable parameters because they are static constants
    Yes, as I already said
    The enum constants are static final instances of the enum class.
    Quote Originally Posted by Xen View Post
    ... and their fields/properties are also static variables.
    No, they aren't. They are instance variables unless declared with the static keyword.

    I think you're confusing enums and interfaces. Interface fields are implicitly public, static and final.

    db
    If you're forever cleaning cobwebs, it's time to get rid of the spiders.

  8. #8
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: Changing a property of an enum

    Quote Originally Posted by DarrylBurke View Post
    No, they aren't. They are instance variables unless declared with the static keyword.
    Hm, so what is the difference? Every enum may be instantiated but there exists only one of each anywhere and hence the variables/properties it can have are as unique as the enum itself.

    I think you're confusing enums and interfaces. Interface fields are implicitly public, static and final.
    No, wasn't aware of that.

  9. #9
    DarrylBurke's Avatar
    DarrylBurke is offline Forum Police
    Join Date
    Sep 2008
    Location
    Madgaon, Goa, India
    Posts
    12,059
    Rep Power
    26

    Default Re: Changing a property of an enum

    Quote Originally Posted by Xen View Post
    Hm, so what is the difference? Every enum may be instantiated but there exists only one of each anywhere and hence the variables/properties it can have are as unique as the enum itself.
    See http://www.java-forums.org/apache-po...tml#post350187

    db
    If you're forever cleaning cobwebs, it's time to get rid of the spiders.

  10. #10
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    13,541
    Rep Power
    27

    Default Re: Changing a property of an enum

    Quote Originally Posted by Xen View Post
    I generally prefer Enums over primitive types. But Enums can be very very very very slow, if you are really with a time-essential operation (such a brute force techniques, path searching, anything that is computationally expensive) then the enum provides for VAST overhead. I don't remember exactly, but I remember enum operations using hidden Maps or Hashtables or something like that. When you decompile an Enum using program, you will find how utterly expensive they are. If you are seriously running the same routine for millions of times, you cannot use enums.
    Have you benchmarked this?

    Quote Originally Posted by Xen View Post
    Sometimes I am willing to go all the way and be able to use e.g. both Enums and Strings, but mostly at this point I go the easy route, and offer my code the choice of using any type of Enum, and I provide type safety (not through generics) but by asserting that the parameters I get are of the same type.

    E.g.

    Java Code:
    public void someMethod(Enum param) {
        assert paramClass.equals(param.getClass()) : "Something is going wrong, badly :P";
    }
    This confuses me a bit since earlier you talk about performance issues, and yet here you are forcing the JVM to do your type safety for you, rather than the compiler.
    Please do not ask for code as refusal often offends.

    ** This space for rent **

  11. #11
    gimbal2 is offline Just a guy
    Join Date
    Jun 2013
    Location
    Netherlands
    Posts
    5,114
    Rep Power
    12

    Default Re: Changing a property of an enum

    I am more confused by the fact that someone who asks questions in "new to java" can make claims of performance that would indicate a vast background of working experience.
    "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis

  12. #12
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: Changing a property of an enum

    Quote Originally Posted by DarrylBurke View Post
    Ok, but I don't see what that adds. Each enum is still a Single Instance Thing including all fields it might have (every individual member of the class is a single thing and every variable is site-wide). So they behave like static variables.

    Quote Originally Posted by Tolls View Post
    Have you benchmarked this?
    Yeah. I was writing a game bot in Java. It was doing my regular mini-max backtracking algorithm (I guess I took some advancement from wikipedia) and using some enums for states. I think the performance of my routine was like 10 times worse when I used enums instead of static final ints. I'm not sure if I have the code still.

    I'm like a data-less man. The only data I have is what is sitting on Github. And a few modest other online backup places. But like I said, I was flabbergasted by the bad performance (this was in 2010 or so) and decided to decompile the thing, and I was shocked.

    I may try to get an archive downloaded from somewhere that has my data but my home server thing doesn't respond.

    What I remember was the code doing a table lookup on every comparison, but I may be mistaken. I could easily reproduce it with a decompiler... Will do that shortly.

    This confuses me a bit since earlier you talk about performance issues, and yet here you are forcing the JVM to do your type safety for you, rather than the compiler.
    Well, I have no performance issues at present, although I'm a bit.. I want my state machine etc. to be fast of course, it can't hog down my application if scaling issues arise. I may try to rewrite the engine using regular primitives to check the performance difference when I have a testing framework.

    But obviously, by default these assertions don't run (you have to supply -ea) which means that in a 'production environment' it is the equivalent of being 'compile time'. But seriously.

    Every time I make a mistake in knowing what object is sitting in what container, I get a quick runtime error with a classcast or anything. Then it is solved. I don't know why the type checking thing is being so overblown. You don't even have type checking in something like .e.g. PHP. What's the big deal. The only purpose these generics really have is to make the code more fluent because you don't have to do any casts.

    I might even start using it for that purpose after all... but I dislike it so much... Maybe sparingly? Now my code is completely generics free :p. Seriously. I don't know what's the big deal about Class<?> c = ...... The only thing it prevents is compiler warnings:

    Java Code:
    [javac] Note: Some input files use unchecked or unsafe operations.
    [javac] Note: Recompile with -Xlint:unchecked for details.
    <-- my bread and butter ;-). You can't turn that compiler warning off, as far as I'm concerned.

    Quote Originally Posted by gimbal2 View Post
    I am more confused by the fact that someone who asks questions in "new to java" can make claims of performance that would indicate a vast background of working experience.
    Euhm.. just an issue with not knowing where to post. I guess it could have gone to Advanced Java but I thought my initial enums question was rather simple.

  13. #13
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: Changing a property of an enum

    Well, nothing much odd or fancy about the code I am getting. The only interesting part is the switch statement:

    Java Code:
    switch (.$SwitchMap$EnumTest2$Test[test.ordinal()]) {
        case 1: 
        case 2: 
        case 3: 
        case 4: {
            System.out.println((Object)test);
        }
    }

  14. #14
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    13,541
    Rep Power
    27

    Default Re: Changing a property of an enum

    I'm curious to know what it was you were doing with enums that produced your issue.
    A simple enum with values simply representing state doesn't produce any odd code.

    For example the following produces almost identical bytecode:
    Java Code:
        private static int textTest(AnEnum anEnum) {
            if (anEnum == AnEnum.THIS) {
                return 1;
            } else {
                return 0;
            }
        }
    
        private static int textTest2(int i) {
            if (i == 2) {
                return 1;
            } else {
                return 0;
            }
        }
    The enum one compares addresses, and the int compares value...the end result being both compare the value of the variable.

    As for compile time type checking, it's been accepted as useful because without it it is easier to introduce bugs.
    Squashing bugs is more time consuming than simply having the compiler inform you of the problem waaaay before runtime.
    Pre-generics collections were a bit of an issue, for example.
    Please do not ask for code as refusal often offends.

    ** This space for rent **

  15. #15
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: Changing a property of an enum

    I may have been overstating it a bit. I guess what it came down to that the most executed routine in my program was very small and it probably entertained a switch statement. The switch statement introduced another function call (method call) and an array lookup. This caused the program to be much slower. Something like that. Nothing exageratingly large, it was just relevant for that routine at least.

    Ah, I believe that was also when I was looking into the java BitSet :D. A BitSet is actually very well indicated and constructed. It is a marvel of engineering!

    I'm not even against generics but against the way it was created as part of the language, not just an annotation system (which it should be) but an integral part of the language itself. That is not good. That is not right. You could easily create something that would indeed function as annotations in a way that the main language doesn't suffer. From the way it is now positioned it is not apart from the language but a part of the language, and this frustrates because in the end it is nothing real: the code is not turned into bytecode. The code serves to alleviate issues with casting in collection class and other forms of containing classes.

    It looks like it is part of the language and will actually do compile-things, but it does not. It does instruct the compiler to treat your code differently of course. But you could decompile and it'd be gone. Such a feature must be 'optional' or 'standalone' and you can hardly argue that generics are really optional.

    The mess you create (and that I force myself to endure) is just as great as the mess you have when you do use it :p.

    For me the turning point was when I read my old generics code, which was perfectly fine, and I couldn't for the life of me understand what it said. That was because I hadn't been programming for a while.

    I never have such incomprehension with general java code.

    When something is incomprehensible, you know it is not right. It may very well confuse your mind and lower your productivity.

    Java Code:
    List<String> list = new ArrayList<String>();
    list.add("hello");
    String s = list.get(0);   // no cast
    These annotations are littered everywhere! This fragment is actually more verbose than the none-using fragment:

    Java Code:
    List list = new ArrayList();
    list.add("hello");
    String s = (String) list.get(0);
    The newer versions of Java I believe introduced a shorthand:

    Java Code:
    List<String> list = new ArrayList<>();
    list.add("hello");
    String s = list.get(0);   // no cast
    which they call diamond notation. But you would think that something like this would suffice:

    Java Code:
    List list = new ArrayList<String>();
    list.add("hello");
    String s = list.get(0);
    but you need to annotate every declaration of every variable.

    In any case I think I'm going to sparingly introduce a bit of generics again to the collection classes I use, because it is a mess like this (all the casts you require). When done right I think it shouldn't give all that much clutter.

  16. #16
    jim829 is offline Senior Member
    Join Date
    Jan 2013
    Location
    Northern Virginia, United States
    Posts
    6,226
    Rep Power
    14

    Default Re: Changing a property of an enum

    When something is incomprehensible, you know it is not right. It may very well confuse your mind and lower your productivity.
    Have you read any books on generics to help you understand them better? You also seem to understand them enough to discuss their syntax to some degree. But if you really don't understand them, then post a question. Someone may be able to help you.

    Generics is not about making things less verbose. It's about catching potential run-time errors at compile time. It also cleans up the code by making casts unnecessary. And to measure productivity, you need to look at the long term. Imagine, an error that creeps in a year or two later that generics would have caught. Now you have to revisit the code (which may be temporarily incomprehensible) and try to fix the problem.

    And for the record, I cannot look at generics declarations on methods and instantly know what is going on. I have to think about it. Sometimes I have to get one of my books and check it out. I also have to try different things with them. To me they are not intuitive. But I find them very useful.

    And I too also have occasional questions about syntax. Like why not

    Java Code:
    int a = new int[10];
    Shouldn't the compiler be able to figure that one out too. But I presume that the designers had concerns so they did it the current way. And somewhere I read that in one of the C variants, the spaces must surround < > when using them. Java got around that requirement.

    Regards,
    Jim
    The JavaTM Tutorials | SSCCE | Java Naming Conventions
    Poor planning on your part does not constitute an emergency on my part

  17. #17
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    13,541
    Rep Power
    27

    Default Re: Changing a property of an enum

    Trivial examples are, well, trivial.

    To take your 3rd example:
    Java Code:
    List list = new ArrayList<String>();
    list.add("hello");
    String s = list.get(0);
    Not having the type on the left raise a problem here:
    Java Code:
    List getSomething();
    What class are the contents of the returned List?

    That's why they chose the right hand side for the <>.
    It's the type of the variable you are interested in, not the object on the heap.
    Please do not ask for code as refusal often offends.

    ** This space for rent **

  18. #18
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: Changing a property of an enum

    Quote Originally Posted by jim829 View Post
    Have you read any books on generics to help you understand them better? You also seem to understand them enough to discuss their syntax to some degree. But if you really don't understand them, then post a question. Someone may be able to help you.
    Nah. What I'm saying is not that I lack intellectual quality, but that the thing itself is incongruent with itself. Which you also experience, I believe. (Below).

    Generics is not about making things less verbose. It's about catching potential run-time errors at compile time. It also cleans up the code by making casts unnecessary. And to measure productivity, you need to look at the long term. Imagine, an error that creeps in a year or two later that generics would have caught. Now you have to revisit the code (which may be temporarily incomprehensible) and try to fix the problem.
    Yeah, well the latter part is speculating for me.

    And for the record, I cannot look at generics declarations on methods and instantly know what is going on. I have to think about it. Sometimes I have to get one of my books and check it out. I also have to try different things with them. To me they are not intuitive. But I find them very useful.
    That's exactly what I mean! You got it! I mean that the language (of the generics) is in itself a bad language. It is not very readable. It was badly designed. It if was designed rightly then it would read like bliss. That's only common sense.

    And I too also have occasional questions about syntax. Like why not

    Java Code:
    int a = new int[10];
    Shouldn't the compiler be able to figure that one out too.
    In PHP it would. But then, PHP is not typed. But it refers to the example Tolls gives below. By the way, I want to thank you for you guys for an opportunity to talk about this stuff. I have been ...annoyed and griped by this for a long time. But I have no programmers in my environment (in what you'd call real ...life or death). I haven't spoken to a computer programmer since I left university I guess, and that was like 10+ years ago, except for one friend who never liked to talk about it. That aside, I also haven't programmed for a long time due to a form of brain injury.



    Quote Originally Posted by Tolls View Post
    Not having the type on the left raise a problem here:
    Java Code:
    List getSomething();
    What class are the contents of the returned List?

    That's why they chose the right hand side for the <>.
    It's the type of the variable you are interested in, not the object on the heap.
    Perhaps. But are we not always talking of assignments? I would think that the direction of information flows from the heap object to the variable.

    Once you've defined the type of .e.g. collection class, the java compiler can or could infer that the object on the left 'wants' to have the same type, although this is an assumption that might weaken the type checking capability.

    "List getSomething()" is not an expression nor is it a variable declaration, it is an abstract or non-abstract method definition or interface method definition. So that means it is something that is always going to appear on the right hand side of anything. On the other hand, of course, that can also be said of any variable; any variable can turn into an expression. I would expect a good generics declaration to focus on methods and what results from constructors, or, at least, what goes on in a class definition.

    So you'd get

    • method definitions (return types)
    • class signatures
    • parameters for methods (as it coincides with class <types>)
    • results of constructors of typed classes


    I don't think you need anything else. The compiler can infer that any variable that is assigned to should just have the same type, for I believe there are no other sources of type information that you need.

    I'll just do a little test... just wanted to test some "Class<?> c = .getClass()" behaviour. Indeed Class<?> is the only signature you may give it:

    Test.java:7: error: incompatible types: Class<CAP#1> cannot be converted to Class<Some>
    Class<Some> c = Some.YES.getClass();
    ^
    where CAP#1 is a fresh type-variable:
    CAP#1 extends Some from capture of ? extends Some
    This piece of error code is just completely, utterly, beautifully and magnificently unreadable to me. It is a thing of utmost beauty for how stupid and mundanely utterly incomprehensible it is :D. It should win a reward :D.

    Annotations are also meant to make your code more readable, but I think these generics fall short of their mark.

    So, with that weaker-type-checked system I'd propose (currently) the compiler would have to infer more and just track variables and see how they're used, with the benefit that although you lose some immediate type checking, what you win is still free casting :D.

    For the simple reason that the type of every heap object will be known. So assignments should be bliss :D.

  19. #19
    jim829 is offline Senior Member
    Join Date
    Jan 2013
    Location
    Northern Virginia, United States
    Posts
    6,226
    Rep Power
    14

    Default Re: Changing a property of an enum

    As you can tell I have been advocating the use of enums and EnumSets instead of bit fields. So when reading about SplitIterator<T> I was surprised that Spliterator.characteristics() returned an or'd bit field instead of an EnumSet. A little searching found this on SO. I suggest you also read the identified email discussion between Josh Bloch and Doug Lea. Very interesting.

    Justification for using a bitfield instead of EnumSet in modern Java 8 API - Stack Overflow

    Regards,
    Jim
    The JavaTM Tutorials | SSCCE | Java Naming Conventions
    Poor planning on your part does not constitute an emergency on my part

  20. #20
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    13,541
    Rep Power
    27

    Default Re: Changing a property of an enum

    (This was eaten by a forum glitch yesterday)

    Quote Originally Posted by Xen View Post

    "List getSomething()" is not an expression nor is it a variable declaration, it is an abstract or non-abstract method definition or interface method definition. So that means it is something that is always going to appear on the right hand side of anything. On the other hand, of course, that can also be said of any variable; any variable can turn into an expression. I would expect a good generics declaration to focus on methods and what results from constructors, or, at least, what goes on in a class definition.
    Java Code:
    List myList;
    
    if (some condition) {
        myList = new ArrayList<String>();
    } else {
        myList = new ArrayList<Foo>();
    }
    myList.get(0).someMethodOnFoo();
    If you want compile time type safety, and that is what generics were introduced for, it is the variable that needs to be tagged with the generic, otherwise how do you handle the above? You're barely better off than pre-generics.
    Please do not ask for code as refusal often offends.

    ** This space for rent **

Page 1 of 2 12 LastLast

Similar Threads

  1. Help with changing a Book Enum to a Book Class
    By Dragrain in forum New To Java
    Replies: 1
    Last Post: 12-06-2012, 07:18 PM
  2. public static enum vs enum class
    By Dipke in forum New To Java
    Replies: 3
    Last Post: 08-30-2011, 10:45 AM
  3. Setting values from One Enum type to another enum type.
    By reach2sudhakar in forum New To Java
    Replies: 3
    Last Post: 09-23-2010, 06:02 PM
  4. Replies: 0
    Last Post: 08-14-2010, 10:09 AM
  5. Replies: 0
    Last Post: 06-25-2009, 05:28 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •