tag:blogger.com,1999:blog-741750605858169835.post52725258652298251..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Java language - Enum SwitchStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-741750605858169835.post-17248479568614459442007-02-15T18:25:24.000+00:002007-02-15T18:25:24.000+00:00Ricky: "assuming you need to do different thi...Ricky: "assuming you need to do different things for different instances of Color, which in itself would be strange".<br /><br />What about:<br /><br />GREEN:accelerate();<br />AMBER:accelerateReallyFast();<br />RED:accelerateReallyReallyFastAndScream();<br /><br />Notice I couldn't really follow these with break;<br /><br />Who says the old uns aren't the best ;)<br /><br />rwt @CompleteEnumSwitch and @NoFallThroughSwitch - I'm in favour of both suggestions - anything that makes switches less prone to error has to be good.Bad Drivernoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-80348900614033915852007-02-15T07:01:46.000+00:002007-02-15T07:01:46.000+00:00YES,WATHEVER THE INFORMATION I GOT FROM HERE IT IS...YES,WATHEVER THE INFORMATION I GOT FROM HERE IT IS SOMEWHAT EASY FOR ME TO UNDERSTANDPREMKHITnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-48033614860965335122007-02-05T22:59:40.000+00:002007-02-05T22:59:40.000+00:00Well, thanks for the compliment on my post.
I thi...Well, thanks for the compliment on my post.<br /><br />I think macros are somewhat completely different to closures. As with the default statement, as far as I can see, closures only would give a runtime check on completeness, as the compiler would not know about what completeness in calling a closure means. One would need to add the information on enums as kind of distinctive cardinality to a VarArg-like argument construct or add meta-information to add explanations for the compiler.<br />But maybe I am thinking too complicated :)<br /><br />A Macro, on the other hand, would be some kind of ruleset, which tells the compiler how to construct the desired Java code from a given macro usage. Of course, a ruleset could contain constraints on what to build and fail or warn at compile time. But I would wonder, if anyone wants to have macros being introduced to Java.Stefan Schulzhttp://jroller.com/page/jaddanoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-49833882525140764982007-02-05T20:01:38.000+00:002007-02-05T20:01:38.000+00:00Stefan,
I liked your multipiece method names post...Stefan,<br /><br />I liked your multipiece method names post, indeed.<br /><br />Closures would help in deciding upon completeness simply by making it clear what kind of switch statement you want. Imagine we have a similar proposal to closures, but for macros, and that completeSwitch is such a macro.<br /><br />import static java.lang.Control.completeSwitch;<br /><br />completeSwitch(enumValue)<br />{<br /> case ONE:<br /> return 1;<br /> etc.<br />}<br /><br />Then it could be clear to an IDE whether you want a complete switch or not, and more readable (subjective) than:<br /><br />@CompleteSwitch<br />switch (blah)<br />{ etc }<br /><br />It might be possible using your multipiece method names idea to make the above happen with closures, albeit with other syntax.Ricky Clarksonhttp://cime.net/~ricky/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-59830444878054468742007-02-05T18:13:20.000+00:002007-02-05T18:13:20.000+00:00@Ricky
I know, defaults are runtime only. But chec...@Ricky<br />I know, defaults are runtime only. But checking for such pitfalls at compile time may as well stay an IDE feature. I just don't want to see third-party code breaking, which I am actually only using in my application.<br />Regarding annotations-anywhere I don't see the point of cluttering, as a decent programmer would have to document that fact of what gets suppressed on the spot anyway. For local variable definition using annotation already is possible, btw.<br />I'm not sure about the connection to closures, but for making methods like a completeSwitch readable, one would need another extension to Java (e.g. Multipiece Method Names, as shown on my blog). I just don't see, how closures will help on deciding upon completeness, though.Stefan Schulzhttp://jroller.com/page/jaddanoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-8310152734516734022007-02-05T17:35:39.000+00:002007-02-05T17:35:39.000+00:00Correction, Herman said that Eclipse supports the ...Correction, Herman said that Eclipse supports the inspection too.<br /><br />Stephen, when you say that Eclipse's setting is global - it's a per-project setting. I think that's granular enough. If not, then you probably want a way of telling Eclipse not to give a warning for a particular switch statement, the inverse of your annotation - @IncompleteSwitch (meaning "yes, I know it's incomplete, trust me.").<br /><br />Vivek,<br /><br />The problem with your approach is that it puts the responsibility in the wrong place. A Color shouldn't know how to save itself to disk or make itself appear on the screen, for example. That's what dynamic dispatch (the visitor pattern in Java) is for, assuming you need to do different things for different instances of Color, which in itself would be strange.<br /><br />Stefan,<br /><br />Making default cases doesn't help to achieve compile time completeness, because forgetting to add code for a case won't show up at compile time with a default case present. That takes you to dynamic checking, which is possibly a bad thing in a language with a less sophisticated error-handling system than, say, Common Lisp's.<br /><br />Also, I think @SuppressWarnings gets in the way of reading code; one programmer's idea of what should be suppressed is different to anothers, and even one programmer may change his mind. It's better to set it in another part of the code, e.g., instead of using the language construct 'switch', use a method call, 'completeSwitch'. I don't think the closures proposal goes far enough to make that convenient though.<br /><br />Suggested syntax for making annotations available on arbitrary statements - make them available on blocks:<br /><br />@SuppressWarnings("unchecked")<br />{<br /> List l=new ArrayList[String]();<br />}Ricky Clarksonhttp://cime.net/~ricky/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-86483083017716946162007-02-05T17:22:29.000+00:002007-02-05T17:22:29.000+00:00Stephen,
IDEA actually has an inspection for inco...Stephen,<br /><br />IDEA actually has an inspection for incomplete switches on enums. I don't think Eclipse does. If this inspection were standard (across both IDEs) then I'm not sure what benefit you'd get from making a completeSwitch part of the language. Further, without IDE support most programmers would be unlikely to bother using the annotation,, or would forget sometimes.<br /><br />Fabrizio,<br /><br />Presumably you would replace the enum switch with a visitor implementation. These are very verbose, a little hard to read, and don't scale well. E.g., when a class can accept more than one type of visitor, it gets awkward to see which is which.<br /><br />In comparison to the intention, which is clearly expressed in a switch statement, visitor makes flow harder to understand.<br /><br />The only real fault of switch (on enums at least) is break. Arguably it was a design mistake to allow incomplete switches on enums in the first place - if more Java forms were expressions rather than statements then more thought would go into things like this. In other words, if switch returned something, we'd already have the completeness checking. It can't be added as a compile error, and I don't think new warnings should appear (by default at least) for existing code; that was one of the things that scared some people into staying with 1.4.Ricky Clarksonhttp://cime.net/~ricky/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-31822247123164736862007-02-05T11:17:31.000+00:002007-02-05T11:17:31.000+00:00If we talk about best programming practices, then ...If we talk about best programming practices, then the whole point is meaningless since you simply shouldn't be using a switch :-)<br /><br />But the idea of adding a compiling-time validating annotations is different from a best programming practice, such as the default case, since it's a compiler rather runtime test. So IMHO the annotation proposed by Stephen is worth while.Fabrizio Giudicihttp://weblogs.java.net/blog/fabriziogiudicinoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-16862937638169265742007-02-02T20:50:30.000+00:002007-02-02T20:50:30.000+00:00Adding such an annotation seems useful at a first ...Adding such an annotation seems useful at a first glance. But maybe, using enums in switch statements should require to have a default statement to guarantee a valid state in case of adding a value to the enum (at least, the programmer has to take it into account).<br /> <br />Other than that, there is a general need for being able to attach annotations to statements other than assignments: A problem I often encounter is the need for SuppressWarnings to mark unchecked casts or autounboxing (and autoboxing, as eclipse does not allow to select warning for boxing/unboxing seperately) situations, which I checked and know of being safe. Usually, I have to put the annotation to the method, which may hide other issues and requires additional comments to explain where and why the annotation was added. This would be much clearer having the annotation where it belongs.Stefan Schulzhttp://jroller.com/page/jaddanoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-11056738879609669492007-02-02T19:28:31.000+00:002007-02-02T19:28:31.000+00:00I'd like to see something done at the Map leve...I'd like to see something done at the Map level. I practically never use switch statements, but do make use of maps () as dispatch tables. So the "switch" is generated at runtime, possibly dynamically through a configuration, and is a little more OO.<br /><br />Similar coverage issues come into play as you've outlined. It would also be nice to map a range of values to a single instance of an interface. Or, more generally, map on an arbitrary boolean instead of just equals.<br /><br />Some sort of Map extension or other Collections API improvement, with a cook() method to JIT compile the cases for optimization and speed would be a welcome improvement. This would also help you with your runtime needs.gjfdhnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-91473869677770567922007-02-02T17:33:39.000+00:002007-02-02T17:33:39.000+00:00There is an alternative to what you've suggest...There is an alternative to what you've suggested, Stephen:<br /><br />If you move the code related to each enum type into a method on the enum, then the need for the switch statement vanishes.<br /><br />Color col = ...<br />col.doSomething();<br /><br />doSomething() would, of course, need to be implemented for each color.Vivek Prahladhttp://blog.vivekprahlad.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-31821118958293675072007-02-02T16:43:23.000+00:002007-02-02T16:43:23.000+00:00Men, U complex the simple thing...
U can just add...Men, U complex the simple thing...<br /><br />U can just add a default case to the switch...<br />and throw a AssertException or something else in the default case.M.noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-89604007699678685262007-02-02T14:42:15.000+00:002007-02-02T14:42:15.000+00:00Well, this is an annotation, sounds like it's ...Well, this is an annotation, sounds like it's a reasonable way to enhance the language.Fabrizio Giudicihttp://weblogs.java.net/blog/fabriziogiudicinoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-67286608809627348222007-02-02T14:34:12.000+00:002007-02-02T14:34:12.000+00:00@Herman, I know about that setting, but its global...@Herman, I know about that setting, but its global. This concept allows you to choose the setting per switch statement.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-30783957244133280462007-02-02T14:01:58.000+00:002007-02-02T14:01:58.000+00:00In Eclipse you can set a compiler flag: "Enum...In Eclipse you can set a compiler flag: "Enum type constant not covered on 'switch'". This'll result in the same the kind of functionality. Your other idea is also available under the same settings.<br /><br />Hope this helps.Herman van Hovellnoreply@blogger.com