Re: generics and arrays and multi-class collections
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>()
};
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