Re: proposed new definition of preemption

Le 26 feb 2013 à 15:41, chris nuernberger a écrit :

> David, a simplification would be to take the (in general) lcca of the transition's source and it's targets and *then* you can do the descendent check (if either is a descenant of the other then you can't run the later transition).
> If you browse earlier emails you will see that was the algorithm I proposed; it is faster than this one and would get any case correct that this one would get correct.  

I remember. It's a good solution. One reason I still prefer my version is because I have dynamic transitions in JSSC (I have extended transitions with 'targetexpr') and therefore the LCCA might have to be recalculated each time for those, so I'd rather do it only when needed (i.e. when it has already been determined that the transition really must be taken).


> I think you pointed this out but if you want things to work out visually in terms of preemption then you also want to select transitions in reverse child order on the state when you are checking them.  Really, for transitions you want complete reverse document order and this would mean that you could, with your eyes, walk from an activated atom *up* the document and the transition selection process would consistently move *up* the document toward the root.  Currently we sort of move up, then down, then up, then down as you pointed out earlier.  

I don't think so. SCXML being a graphical language, authors should be expected to visualize their SCXML as a state chart, not as raw code. Each state would have a list of transitions (and just one list, not multiple lists interweaved with child states, which was my point), displayed below the state's children, and it seems natural that the top of the list should get looked at first. Thus, graphically, you would consistently look from top to bottom.

			David

Received on Tuesday, 26 February 2013 16:35:17 UTC