Re: generics and arrays and multi-class collections
On Sep 30, 5:45 am, xen <x...@rotmail.nl> wrote:
On 30 sep, 06:02, Daniel Pitts <googlegrou...@coloraura.com> wrote:
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>()
};
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)
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++)"
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
Direction.N is created, Direction.S does not exist yet. If I create a
method opposite() I get
Direction opposite() {
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.