New implementation for Lua tables. Does not use Vector or Hashtable, instead
uses plain Java arrays directly to keep heap allocation to a minimum. Includes some unit tests that seem to indicate the basic operations are correct. However, the following things are not implemented: * Shrinking the capacity when elements are removed * Optimal storage of each element in array vs. hash when entries are added out of order. A junit test case is there for this.
This commit is contained in:
@@ -9,11 +9,15 @@ public class LInteger extends LNumber {
|
||||
public LInteger(int value) {
|
||||
this.m_value = value;
|
||||
}
|
||||
|
||||
public int hashCode() {
|
||||
return m_value;
|
||||
|
||||
public final int hashCode() {
|
||||
return hashCodeOf( m_value );
|
||||
}
|
||||
|
||||
|
||||
public static int hashCodeOf( int v ) {
|
||||
return v;
|
||||
}
|
||||
|
||||
public int luaAsInt() {
|
||||
return m_value;
|
||||
}
|
||||
@@ -22,6 +26,10 @@ public class LInteger extends LNumber {
|
||||
return String.valueOf(m_value);
|
||||
}
|
||||
|
||||
public boolean isInteger() {
|
||||
return true;
|
||||
}
|
||||
|
||||
// binary operations on integers, first dispatch
|
||||
public LValue luaBinOpUnknown(int opcode, LValue lhs) {
|
||||
return lhs.luaBinOpInteger( opcode, this.m_value );
|
||||
|
||||
Reference in New Issue
Block a user