I think this interface should be removed. It is implemented by exactly 1 enum and its existence prevents me from writting a switch statement on the enum constant.
I'd like to be able to write, in a Visitor
public void visitConditionalBranch(SSAConditionalBranchInstruction ins) {
switch(ins.getOperator()){
EQ: .....
NE: .....
}
}
Removing the interface would allow that code.
(the above is valid unless there's a deeper reason for the interface's existence)
Logged In: YES
user_id=221724
Originator: NO
I don't think I'm in favor of this.
The intention behind the IOperator is to not hard-code these 6 Java conditions, since we intend the IR to be extensible to support other languages. For many ShrikeBT instructions, JavaScript and PHP add additional operators.
I could easily imagine another language needed a different conditional operator, which would just require fixing this later.
In order to use a switch, you'll have to cast to ConditionalBranchInstruction.Operator. Doesn't seem too bad.
Logged In: YES
user_id=221724
Originator: NO
I don't think I'm in favor of this.
The intention behind the IOperator is to not hard-code these 6 Java conditions, since we intend the IR to be extensible to support other languages. For many ShrikeBT instructions, JavaScript and PHP add additional operators.
I could easily imagine another language needed a different conditional operator, which would just require fixing this later.
In order to use a switch, you'll have to cast to ConditionalBranchInstruction.Operator. Doesn't seem too bad.
Logged In: YES
user_id=403488
Originator: YES
Sounds like speculative genericity to me.
If other languages come up, then the interface can be added back, or another solution can be considered.
Before those languages come up, the interface just gets in the way.
And the cast is kind of nasty. If more things implement the interface in the future, my code will not stop compiling but will just break without warning.
But I can live with the interface if it stays.