 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2007generics and arrays and multi-class collections
Yo peoples of the earth, What is the proper use of generics when you want to use arrays as well? Is there anybody out there that writes code that does NOT generate unchecked warnings? For example, java.util.ArrayList uses an array of Object to store its elements, and uses a cast (E)elements[i] to retrieve them, which generates an unchecked warning. I myself have wanted to use an array of generified sets, so I just create a Set[] and assign it to a Set<E>[], which generates a warning. I can trim down on the warnings so that I only get "unchecked conversion" and "unchecked cast" warnings, but it seems I'll have to live with those. My last addition was a Map that can store Lists that store different classes that are all decendants of a superclass: Map<Class<? extends Feature>, List<? extends Feature>> stores; stores = new HashMap<Class<? extends Feature>, List<? extends Feature>>(); I want a method that retrieves each store, and creates one if not present. public <F extends Feature> List<F> getStore(Class<F> c) { List<F> L = (List<F>)stores.get(c); // unchecked cast if (L == null) { L = new ArrayList<F>(); stores.put(c, L); } return L; } The cast generates an unchecked warning. Now given class Block extends Feature {} I can do List<Block> = getStore(Block.class); which is what I wanted. What are your experiences, any advice? greetings, xen. > Yo peoples of the earth, > [quoted text clipped - 41 lines] > > greetings, xen. In my opinion, using Arrays is akin to the "primative obsession" anti- pattern. You'd probably be better off using a List<Set<T>> or simply List<T>, depending on your needs. The little bit of overhead you incur is *far* outweighed by the functionality gained. On Sun, 30 Sep 2007 04:02:20 -0000, Daniel Pitts <googlegroupie@coloraura.com> wrote, quoted or indirectly quoted someone who said : >In my opinion, using Arrays is akin to the "primative obsession" anti- >pattern. You'd probably be better off using a List<Set<T>> or simply >List<T>, depending on your needs. To me the mess is generics. It is overly complicated, does not work with sterilisation. It OOKS ugly and tacked on as an after thought. For more details see http://mindprod.com/jgloss/serialization.html  SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > In my opinion, using Arrays is akin to the "primative obsession" anti- > pattern. You'd probably be better off using a List<Set<T>> or simply > List<T>, depending on your needs. > > The little bit of overhead you incur is *far* outweighed by the > functionality gained. The point is that these arrays are static 2-size arrays that I can initialize really quick with a Set<Move>[] tempCaptures = new HashSet[] { new HashSet<Move>(), new HashSet<Move>() }; There's just no point in using a List. I don't need dynamic expansion. I don't need to treat it as a Collection, or get default toString() functionality, or use any of those nifty java.util.Collections operations. And sometimes the overhead is huge. For example, I'm using bitsets to represent the occupation of a game board. If I use java.util.BitSet, I get lots of built-in functionality. But using somebitset.or(someother) takes 10(!) times as much time as using primitive bit operations on a long, because it has support for bitsets that span more than one long, whereas I need only one, and it does some checks to make sure its own operations don't corrupt it. Although I could have created my own class specially tailored to my needs, even that I haven't done. It would have saved me some debugging time, but I just happen to like "long neighbours = (occupation[0] | occupation[1]) & f.neighbourSet()" and "long available = emptyFields & ~territory[0] & ~territory[1]" and "inters[player] |= 1L << i" --- instead of using more elaborate method calls, using (BitSet)bs.clone() everytime I need a copy, etc. I find my code to be a lot cleaner. Btw, I find that also to be a major drawback of java enumerations. In my current project I have a couple of enumerations that I need to iterate on, but often not on all of the values. So I started using "for (int i = Player.WHITE.ordinal(); i <= Player.BLACK.ordinal(); i+ +) {}" which caused significant overhead compared to "for (int i = WHITE; i <= BLACK; i++)" I also needed to convert one enum constant into another. I couldn't make them refer to each other at creation time, because when Direction.N is created, Direction.S does not exist yet. If I create a method opposite() I get Direction opposite() { return values()[ordinal() ^ 4]; } which is two extra method calls and an array access for a method that is called zillions of times (well this one isn't, but another one is). And then you have the fact that you can't have the enum constants be part of the namespace of the class that declared the enum, so you end up using Move.Type.NORMAL instead of Move.NORMAL every freakin time. I also found that when you do a switch on an enum variable, the compiler creates a static inner class with an array indexed by Enum.ordinal() and filled with 1,2,3,... and then uses these values as labels for the cases, because a switch can only use literal case values and an enum is composed of objects... Anyway, I don't like them too much. Enums in pascal were much nicer. The only advantage is that you can call methods on them, and there is the type safety, but you only need that if you have complex methods that take different kinds of options in seemingly random order. Now I have to call Player.opponent(player) each time instead of player.opponent(), although player ^ 1 would also work ;). Yeah I could use static imports but I can't use that. greets, xen > > In my opinion, using Arrays is akin to the "primative obsession" anti- > > pattern. You'd probably be better off using a List<Set<T>> or simply [quoted text clipped - 9 lines] > new HashSet<Move>(), new HashSet<Move>() > }; Let me guess, you use something like "tempCaptures[playerNumber]" You could always "wrap" your sets with a more meaningful and specific class: class PlayerData { private Collection<Move> tempCaptures = new HashSet<Move>(); // other player specific data and methods } > There's just no point in using a List. I don't need dynamic expansion. > I don't need to treat it as a Collection, or get default toString() > functionality, or use any of those nifty java.util.Collections > operations. For an array that is ALWAYS two sized, I agree, you probably don't need a Collection of any sort (unless the Java API finally adds a Pair type Collection). > And sometimes the overhead is huge. For example, I'm using bitsets to > represent the occupation of a game board. Why? Did you run out of memory when you did it the other way? Was it too slow? Sometimes programmers (including me) optimize WAY too soon. Most experienced OO programmers will start with using objects and classes for everything, and then optimize -- with the help of profiler -- down to using primitives and other hacks. > If I use java.util.BitSet, I > get lots of built-in functionality. But using somebitset.or(someother) [quoted text clipped - 16 lines] > +) {}" which caused significant overhead compared to "for (int i = > WHITE; i <= BLACK; i++)" Why are you dealing with the ordinals at all? That will break things if you change the order, or add new players. (Also, it sounds more like an PlayerColor enum, rather than a Player enum) enum PlayerColor { White, Black; } for (PlayerColor playerColor: PlayerColor.values()) { System.out.println(playerColor); } > I also needed to convert one enum constant into another. I couldn't > make them refer to each other at creation time, because when [quoted text clipped - 3 lines] > return values()[ordinal() ^ 4]; > } How about: enum Direction { NORTH { public Direction opposite() { return SOUTH; } }, SOUTH, { public Direction opposite() { return NORTH; } }, EAST, { public Direction opposite() { return WEST; } }, WEST, { public Direction opposite() { return EAST; } }, public abstract Direction opposite(); } > which is two extra method calls and an array access for a method that > is called zillions of times (well this one isn't, but another one is). Don't be so obsessed with the underlying mechanics UNTIL it becomes a problem. > And then you have the fact that you can't have the enum constants be > part of the namespace of the class that declared the enum, so you end > up using Move.Type.NORMAL instead of Move.NORMAL every freakin time. Java attempted to do that, how would this work: class MyClass { enum Foo { JOE, BOB, CHARLES } enum Bar { JOSEPH, ROBERT, CHARLES } public static void handle(Foo foo) {} public static void handle(Bar bar) {} } MyClass.handle(MyClass.CHARLES); // Whoops, ambiguity! Why would it be the namespace of the owning class anyway, since enums actually can live on their own: -- MyEnum.java -- public enum MyEnum { A, B, C } -- OtherClass.java -- public class OtherClass { public MyEnum value = MyEnum.A; } > I > also found that when you do a switch on an enum variable, the compiler > creates a static inner class with an array indexed by Enum.ordinal() > and filled with 1,2,3,... and then uses these values as labels for the > cases, because a switch can only use literal case values and an enum > is composed of objects... You usually shouldn't switch on enums, you should use polymorphism instead. Again, Don't worry so much about under the hood. This level of obsession with minutia tends to create terrible design. > Anyway, I don't like them too much. Enums in pascal were much nicer. No they weren't. They were much less OO (which is what you seem to have a hard time with) > The only advantage is that you can call methods on them, and there is > the type safety, but you only need that if you have complex methods > that take different kinds of options in seemingly random order. Now I > have to call Player.opponent(player) each time instead of > player.opponent(), although player ^ 1 would also work ;). Yeah I > could use static imports but I can't use that. You could use static imports, but you can't use that? That doesn't make sense... Why can't you have player.oppenent()? enum PlayerColor { White { public PlayerColor opponent() { return Black; } }, Black { public PlayerColor opponent() { return White; } }; public abstract PlayerColor opponent(); } PlayerColor player = PlayerColor.Black; System.out.println(player.opponent()); > greets, xen I hope this makes sense to you, and that you find it helpful. I was once like you, trying to make sure that my code was as optimized as possible all the way through. I spent more time creating the program, and the program usually ended up SLOWER and BUGGIER than when I followed good OO design principals. Hey Daniel, thanks for the elaborate reply. > Let me guess, you use something like "tempCaptures[playerNumber]" > You could always "wrap" your sets with a more meaningful and specific > class: > class PlayerData { > private Collection<Move> tempCaptures = new HashSet<Move>(); > // other player specific data and methods} Yes I could do that but these two objects exists only during the execution of some set of methods that use it to communicate results, it would make no sense to make anything persistent out of it. You are right that I use playerNumber to index the arrays. Most of these arrays exist only during the duration of a method call or even a code block. > > And sometimes the overhead is huge. For example, I'm using bitsets to > > represent the occupation of a game board. [quoted text clipped - 4 lines] > and classes for everything, and then optimize -- with the help of > profiler -- down to using primitives and other hacks. I'm not using the bitsets as the main representation. I'm using a Board composed of Fields that probably should contain Stones (now an int attribute). I'm using the bitsets only as a computational tool, because creating Sets of Fields would be many many MANY times slower. I update the bitsets on each move perform and undo, and use them for territory analysis and such, and to select between different variations of algorithms that tend to perform better in some situations and worse in others. > > Btw, I find that also to be a major drawback of java enumerations. In > > my current project I have a couple of enumerations that I need to [quoted text clipped - 16 lines] > > } I'll never have to change the colors, or the order. Actually its not Player but Stone, and Stone has WHITE, BLACK, NONE due to the fact that I don't use Stone objects (may start using them though, but I'd get field.stone().color instead of field.stone() - there is no other use for the existance of a Stone object than to hold a color so it only makes conceptual sense). An Enum with only two values would indeed allow me to do a foreach on them, which I need to do a lot. > > I also needed to convert one enum constant into another. I couldn't > > make them refer to each other at creation time, because when [quoted text clipped - 28 lines] > > public abstract Direction opposite();} Ah! I hadn't thought of that. I had tried to use constructors with paramters like NORTH(SOUTH), SOUTH(NORTH), ... Direction(Direction op) { this.opposite = op } which didn't work. > > which is two extra method calls and an array access for a method that > > is called zillions of times (well this one isn't, but another one is). > > Don't be so obsessed with the underlying mechanics UNTIL it becomes a > problem. Well, you see, at first I did use Enumerations. For example, the Direction Enum was used in two methods that in current implementation take up about 37% of processing time. Then I wanted to know what the incurred overhead was. I changed the lines for (Direction d: Direction.values()) into for (int d = 0; d < 8; d++) and made sure that the methods called on d also accepted ints. Then I measured execution times. I found that the performance gain was significant. Changing these lines back again just now causes a 15% increase in execution time. That means that for those methods it meant an increase of 41% in execution time. 41%!!! (This also entails a call to ordinal() in getAdjacent()). Granted, the inner loop only contains 13 lines of code, but this is massive overhead. Right now, these methods comprise a larger part of execution time than they probably will in the future, but they will only be surpasses by methods that also make extensive use of these kind of loops. 15% is unacceptable. Btw, the generated code is this: Direction arr$[] = Direction.values(); int len$ = arr$.length; for(int i$ = 0; i$ < len$; i$++) { Direction d = arr$[i$]; So the overhead is basically a method call, an array indexing, and two more method calls in the body of the loop. That's why I don't want "just a couple of calls" inside any inner loop in this program. I'm also using the Direction constants to index an adjacency table, to quickly get the neighbouring fields of a field. Using a table is twice as fast as calculating the indeces each time. (And Field.getAdjacent() makes up 17% of processing time). What would you suggest I do? Create a HashMap that retrieves neighbours based on Directions for each field? I would expect access times at least to quadruple. So I need these ordinal values. The order isn't going to change anyway. And I need the ordinal values of the player colors because I'm not about to create a Map each time I need an array of 2. (Although the most efficient special purpose Map might have some advantage because it can just do V get(K k) { return k == Color.WHITE ? value1 : value2; } > > And then you have the fact that you can't have the enum constants be > > part of the namespace of the class that declared the enum, so you end [quoted text clipped - 21 lines] > public class OtherClass { > public MyEnum value = MyEnum.A; It doesn't have to be default. Just some kind of within-class import static feature. The reason I can't use static imports is because I need to distribute the complete source of the program in one file (it's a bot programming competition). Right now I all have different files, but to submit I have to junk everything in one file with one public class. Static imports would only make things worse, because I'd have to refit every occurence with the class name. (But I could be wrong. Is there a way to use static imports in one and the same file?) > You usually shouldn't switch on enums, you should use polymorphism > instead. What do you mean? > > Anyway, I don't like them too much. Enums in pascal were much nicer. > > No they weren't. They were much less OO (which is what you seem to > have a hard time with) OO isn't the magical solution for every possible situation. At least with pascal or C enums you could create high performance code. > You could use static imports, but you can't use that? That doesn't > make sense... [quoted text clipped - 18 lines] > > System.out.println(player.opponent()); Yes, now I see that I could. Probably not gonna do it though. I'd win some nice syntax but lose some performance (albeit small) and I'd have to write Color.Black.ordinal() all over the place. After tens of array[Color.Black.ordinal()] = object.get(Color.Black.ordinal()) * value array[Color.White.ordinal()] = object.get(Color.White.ordinal()) * value I tend to get a bit tired of this syntax. array[BLACK] = object.get(BLACK) * value array[WHITE] = object.get(WHITE) * value Aaah! Don't you just love concise syntax? I do! :) :) :). Uppercase words within square brackets are just beautiful ;). > I hope this makes sense to you, and that you find it helpful. I was > once like you, trying to make sure that my code was as optimized as > possible all the way through. I spent more time creating the > program, and the program usually ended up SLOWER and BUGGIER than when > I followed good OO design principals. Yes it was helpful. It's not like I'm this performance oriented in every application I write. It's just that this particular program is very performance sensitive. I think I'm at an disadvantage already because I use Java, although I tend to profit from the knowhow embedded in methods such as BitMap.nextSetBit() and Long.bitCount() and the clear data model. Other than that, I'm simply not familiar with the FreePascal environment and there's no way I'm gonna use C. I don't like C ;). And Java is quite nice to program in. grtz, xen. > Hey Daniel, thanks for the elaborate reply. > [quoted text clipped - 10 lines] > embedded in methods such as BitMap.nextSetBit() and Long.bitCount() > and the clear data model. I'm not against performance optimizations at all, I'm just saying you should do it as a last step after you've created the "perfect" design (perfect being relative). And you should only do it with the help of profiling tools. In any case, it sounds like you're particular problem needs optimization. Is there some form of time-limit? > Other than that, I'm simply not familiar > with the FreePascal environment and there's no way I'm gonna use C. I > don't like C ;). And Java is quite nice to program in. > > grtz, xen. Java is a lot of fun to program in :-). But whats wrong with C? You can write really elegant programs in C if you know what you're doing. Gotta love function pointers! :-) Well, good luck on your bot competition. Cheers, Daniel. P.S. Ever heard of AT-Robots? Its a robot simulation game where you pit your robot against other programmers' robots. >I'm not against performance optimizations at all, I'm just saying you >should do it as a last step after you've created the "perfect" design >(perfect being relative). And you should only do it with the help of >profiling tools. In any case, it sounds like you're particular problem >needs optimization. Is there some form of time-limit? Yeah, the program has 30 seconds for the entire game, which can last for 200 moves, so I have to fit 100 moves in 30 seconds. >Java is a lot of fun to program in :-). But whats wrong with C? You can >write really elegant programs in C if you know what you're doing. Gotta >love function pointers! :-) Well, I haven't finished the book I was reading on C so my opinion might not be final, but.... I don't like the way the variable declarations have their type mixed with the variable name, that is, a pointer is not char* p, but char *p, and an array of char ptrs is char *p[], and a ptr to an array is char (*p)[], but it kinda makes sense because that's also the way you're going to use the variable. Also, it's stupid that you dereference by *p instead of p* or p^. I think that's the main reason they needed to introduce p->field because you get pretty tired of writing (*p).field. And then there's the lack of nice basic string manipulation. Everything is so bloody low-level. It's like you have to make fire with firestones when you're used to using matches. String ought to be a type, not a bloody pointer to a piece of memory that may or may not have a zero somewhere to terminate it. It's quite cool that you can set up dynamic 3-dimensional arrays but writing the code is a major headache. I've coded in basic, in pascal, in assembler and in java, but i'll never code for fun in C, or even C++. >Well, good luck on your bot competition. Thanks. ... >> Java is a lot of fun to program in :-). But whats wrong with C? You can >> write really elegant programs in C if you know what you're doing. Gotta [quoted text clipped - 12 lines] > think that's the main reason they needed to introduce p->field because > you get pretty tired of writing (*p).field. Take a look at cdecl, e.g. http://www.linuxcommand.org/man_pages/cdecl1.html On the one hand, it makes writing C declarations relatively easy. On the other hand, the fact that such a program exists implies that C declaration syntax is confusing. Patricia >> I don't like the way the variable declarations have their type mixed >> with the variable name, that is, a pointer is not char* p, but char [quoted text clipped - 9 lines] > >Patricia My god, I hadn't even imagined that declarations could be so complex. void (*signal(int x, void (*y)(int )))(int ) { } But I'm sure they can be much, much complexer. > My god, I hadn't even imagined that declarations could be so complex. > > void (*signal(int x, void (*y)(int )))(int ) { } > > But I'm sure they can be much, much complexer. True, but let's be fair - C also has typedef, which lets you hide the real complexity. I wouldn't want to imagine using pointers to functions without typedefs. sherm-- SignatureWeb Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net >> My god, I hadn't even imagined that declarations could be so complex. >> [quoted text clipped - 7 lines] > >sherm-- True, that's probably what I'd use extensively, because my procedural programming experience is mainly Borland Pascal (and Delphi), where you have to 'typedef' almost everything if you want to use pointers, like: type TMatrixPtr = ^TMatrix; TMatrix = object function transpose: TMatrixPtr; // etc end; So, that's not really the point, or not all of it any way. Just all of it together, the 'nature' of C, makes me want to avoid it as much as I can. No amount of tricks or utilities or insight is going to change that. Now my C experience is not much, just one assignment for a basic client/server application in C, and a computer graphics opengl assignment in C++. But I tend to immediately like or dislike a programming language, and I've never found my likings to change. xen Btw, If I hadn't been so busy with optimizing my search algorithm, I wouldn't have discovered that there was a huge optimization for it which was actually quite well known (90% faster), so that now I can search at least 5 ply instead of 4 ply, which is still not very much, but anyway, it means that I will have less need for feature extraction (previously I couldn't even detect some basic 5-move combo's), so my design is actually dependant on my search capabilities. Now that I can see no further improvements I can start to focus on my heuristics. > Yo peoples of the earth, > [quoted text clipped - 41 lines] > > greetings, xen. > I'll have to live with those. Yes. And the SuppressWarnings annotation may be our only feeble solace. Wisdome is "use Java generics only at its shallowest". Anything deeper can become confusing and unworkable. > Yes. And the SuppressWarnings annotation may be our only feeble > solace. Wisdome is "use Java generics only at its shallowest". > Anything deeper can become confusing and unworkable. Aight, I find it to be the most complex part of the Java language, well, the only complex part. I have been trying endlessly to fix some generics code that wouldn't compile, until I read a tutorial and discovered that what I wanted couldn't be done. I now understand most of it, but I wouldn't be surprised if I get bitten by something unseen again. For example, what exactly are the properties of HashMap<Class<? extends Number>, List<? extends Number>> This was the only way to get different kinds of (Lists of) Numbers into the Map, but when I get() a List, I can't add anything into it, unless I cast it, which generates a warning. Well, now I have *some* type safety. > For example, what exactly are the properties of > > HashMap<Class<? extends Number>, List<? extends Number>> I assume that that is a question, despite the lack of punctuation indicating so. The answer is in <http://java.sun.com/docs/books/tutorial/java/generics/wildcards.html> SignatureLew >Is there anybody out there that writes code that does NOT generate >unchecked warnings? Have a peek inside the source for ArrayList. You will see Sun could not do it without suppressing warnings. I get the idea Sun is going to redo generics, perhaps throwing out type erasure and dealing with embarrassments like this. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Sep 30, 1:48 pm, Roedy Green <see_webs...@mindprod.com.invalid> wrote: > >Is there anybody out there that writes code that does NOT generate > >unchecked warnings? [quoted text clipped - 6 lines] > Roedy Green Canadian Mind Products > The Java Glossaryhttp://mindprod.com > Have a peek inside the source for > ArrayList. You will see Sun could > not do it without suppressing warnings. What part of the source do you refer? >What part of the source do you refer? code like this: public <T> T[] toArray(T[] a) { if (a.length < size) // Make a new array of a's runtime type, but my contents: return (T[]) Arrays.copyOf(elementData, size, a.getClass()); System.arraycopy(elementData, 0, a, 0, size); if (a.length > size) a[size] = null; return a; } If you write code like that I think you will get warnings. It has been a while. I was trying to allocate arrays of the given generic type, and was baffled. I used code similar to what I found in Sun's collections and to my surprise discovered it generated warning messages. I asked about it on the newsgroups and the wise ones assured me this was indeed a limitation of Java's genericity design. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Sep 30, 4:08 pm, Roedy Green <see_webs...@mindprod.com.invalid> wrote: > >What part of the source do you refer? > [quoted text clipped - 22 lines] > Roedy Green Canadian Mind Products > The Java Glossaryhttp://mindprod.com Yes. The code you've mentioned does generate an *unchecked* warning. Sun has just ignored it just like us. :):) Roedy Green wrote: >> It has been a while. I was trying to allocate arrays of the given >> generic type, and was baffled. I used code similar to what I found in >> Sun's collections and to my surprise discovered it generated warning >> messages. I asked about it on the newsgroups and the wise ones >> assured me this was indeed a limitation of Java's genericity design. The rule of thumb is, "Generics and arrays don't mix." SignatureLew >The rule of thumb is, "Generics and arrays don't mix." Except that every Collection inside usually has some sort of array. They might not mix, but you have to use them both anyway. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >> Is there anybody out there that writes code that does NOT generate >> unchecked warnings? [quoted text clipped - 3 lines] > to redo generics, perhaps throwing out type erasure and dealing with > embarrassments like this. Just read the language specification sections on Types. There is at least one apology for generics being broken, with a 'promise' to fix them in a later release, "after migration of existing code" (see section 4.7 Reifiable Types). It is really hard to do much with generics without @SuppressWarnings. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.