Package com.ibm.wala.fixpoint
Class AbstractVariable<T extends AbstractVariable<T>>
- java.lang.Object
-
- com.ibm.wala.util.graph.impl.NodeWithNumber
-
- com.ibm.wala.fixpoint.AbstractVariable<T>
-
- All Implemented Interfaces:
IVariable<T>
,INodeWithNumber
- Direct Known Subclasses:
BitVectorVariable
,BooleanVariable
,IntSetVariable
public abstract class AbstractVariable<T extends AbstractVariable<T>> extends NodeWithNumber implements IVariable<T>
Represents a single variable in a fixed-point system.
-
-
Constructor Summary
Constructors Modifier Constructor Description protected
AbstractVariable()
-
Method Summary
All Methods Static Methods Instance Methods Concrete Methods Modifier and Type Method Description boolean
equals(java.lang.Object obj)
int
getOrderNumber()
Variables must allow the solver implementation to get/set an order number, which the solver uses to control evaluation order.int
hashCode()
static int
nextHash()
I know this is theoretically bad.void
setOrderNumber(int orderNumber)
Variables must allow the solver implementation to get/set an order number, which the solver uses to control evaluation order.-
Methods inherited from class com.ibm.wala.util.graph.impl.NodeWithNumber
getGraphNodeId, setGraphNodeId
-
Methods inherited from class java.lang.Object
clone, finalize, getClass, notify, notifyAll, toString, wait, wait, wait
-
Methods inherited from interface com.ibm.wala.util.graph.INodeWithNumber
getGraphNodeId, setGraphNodeId
-
-
-
-
Method Detail
-
equals
public boolean equals(java.lang.Object obj)
- Overrides:
equals
in classjava.lang.Object
-
nextHash
public static int nextHash()
I know this is theoretically bad. However,- we need this to be extremely fast .. it's in the inner loop of lots of stuff.
- these objects will probably only be hashed with each other
AbstractVariable
s, in which case incrementing hash codes is OK. - we want determinism, so we don't want to rely on System.identityHashCode
-
hashCode
public final int hashCode()
- Overrides:
hashCode
in classjava.lang.Object
-
getOrderNumber
public int getOrderNumber()
Description copied from interface:IVariable
Variables must allow the solver implementation to get/set an order number, which the solver uses to control evaluation order. It might be cleaner to hold this on the side, but we cannot tolerate any extra space. TODO: consider moving this functionality to a subinterface?- Specified by:
getOrderNumber
in interfaceIVariable<T extends AbstractVariable<T>>
- Returns:
- a number used to order equation evaluation
-
setOrderNumber
public void setOrderNumber(int orderNumber)
Description copied from interface:IVariable
Variables must allow the solver implementation to get/set an order number, which the solver uses to control evaluation order. It might be cleaner to hold this on the side, but we cannot tolerate any extra space. TODO: consider moving this functionality to a subinterface?- Specified by:
setOrderNumber
in interfaceIVariable<T extends AbstractVariable<T>>
-
-