Move EventB event action generation to use a single helper function.
Moving from the previous function, move the single event generation work to a single function, reducing duplication. Also move some other duplicated lines to single places, reuse common variables, and start actionNo at 1, avoiding an unnecessary addition on each loop iteration. This was just a cleanup, building on the previous commit.
Loading
-
In terms of raw API content, yes they only differ in that parameter. However, there is one important difference, and that is how they walk the table (the contract of which is in the name).
Specifically, Depth first walks the table by descending into each sub grid as early as possible. For EventB, PVS, and SAL, this is exactly what is needed. It also provides the only real solution for easily fetching the output cells. Breadth first will first give the generator all the cells in the current sub grid, before descending. For CVC3/SMTLIB, this is what they really need. Making them use the depth first walker only makes life harder as they will have to implement functionality to emulate the old behaviour.
The interfaces are separate, as it makes it explicitly clear how the generator will be called. While the interfaces could be merged, that would all your generator to be called using the breadth first walker, which won't work. And trying to support that system is far more work then necessary.
Also, I had wanted to actually keep the interfaces the exact same, but neither breadth first generator needed the output cells, and collecting that was considered far too much work based upon the current setup of the data structures (in terms of runtime). I am thinking about re-evaluating that, but for now it simply is not worth it.
Of course, if you can think of a simple way to reduce the number of interfaces without exploding the complexity of any generator, I'm happy to hear it. But the reason for separate interfaces is not due to the parameter difference, and was an explicit design choice, not an accident.
-
Sounds reasonable. But according to your above explanation. We should have a specific abstract method(like DepthFirstTraverse() or BreadthFirstTraverse()) both in DF and BF Generator which is doomed to be override by the class implements the interface. Then the difference should be more clear. Do you think so?
Please register or sign in to comment