Bug with arrays of booleans

[aviad.in...@gmail.com]

Take note of issue 10 (http://code.google.com/p/infomancers-
collections/issues/detail?id=10) and the new test case accompanying
it, called "booleanArray".

The yielder at the moment doesn't handle boolean arrays properly,
particularly because of the bytecode accompanying a boolean array - it
is treated the same as a byte array, even though in actual Java code
the two are *not* interchangeable.

A well crafted bytecode might help, but I don't want to overcomplex
the system more than it is already, so I'm looking for suggestions
(even of well crafted bytecodes :))

The bytecode needs to replace the BALOAD and BASTORE calls, with the
operand stack filled with "arr, index" and "arr, index, byte-value"
for each call, and push a byte-value to the operand stack after the
BALOAD call.

Ideas?

[aviad.in...@gmail.com]

My proposed bytecode segment is as follows:

if (arr.getClass().getComponentType() == Byte.TYPE) {
stack <- Array.getByte(arr, index);
} else { // assuming a BALOAD can only operate on bytes or booleans!
stack <- Array.getBoolean(arr, index);
}
slot$n <- stack

This _can_ be done - but is it the best way?

[aviad.in...@gmail.com]

This bug has been fixed, checked-in, and I've wrapped it in a new
version.

The biggest "feature" of the version is a change in the implementation
- now, each primitive type is associated with a code-creator which
spawns accessors (for arrays and normal fields).

After this refactoring, I've made the Byte array accessor creator to
spawn the following code:

if (arr.getClass().getComponentType() == Byte.TYPE) {
// byte-array methods
} else {
// boolean-array methods
}

Check the code out for specific implementation, obviously.

>From here on, unless I see another crazy bug, the changes are going to
be about optimizing the slot-replacements so that they'd be primitive
types when possible.