- From: Ate Douma <ate@douma.nu>
- Date: Tue, 25 Mar 2014 09:25:19 +0100
- To: www-voice@w3.org
On 25-03-14 08:36, David Junger wrote: > Le 25 mar 2014 à 07:42, Ate Douma <ate@douma.nu <mailto:ate@douma.nu>> a écrit : > >> I agree this should be properly fixed in the algorithm, but I dislike kludging >> some extra attribute on a state object for the duration and scope of one micro >> step only. If possible I'd keep the SCXML element model definitions >> independent of current execution state and context. >> >> A maybe cleaner way to do is to introduce and use a temporary >> table<State.id,Transition> data structure and use that to keep track and look >> up the History transition to be executed when entering a state. >> […] Hmm, not sure where I used anything Java specific in my proposed changes to the Algorithm. I just tried to give an example how the Algorithm night need to be changed, and AFAIK fully in line with how the Algorithm currently is described. Sure, I'm using Java for my implementation but AFAIK nothing I described reflects on any specific implementation language. The table<State.id,Transition> above was just to explain what kind of data would be mapped by the table, nothing more. In Java you actually would use a Map for this, the table data structure is only used in the Algorithm (like elsewhere). > > Who said the pseudocode was Java? Guys, you know you can implement the spec > without transposing the pseudocode word for word, right? > I'm not defending one way to write this or the other, I'm just saying, do > whatever is easier to understand and shorter to read. > Most importantly, describe the intended timing precisely in the prose. > Of course, the specification itself should be leading and exact. I'm just trying to provide an example how the Algorithm *might* be changed to help determine the needed change in the specification. For example the realization that an Initial might target a History and thus its executable content needs to be executed first, became only obvious to me after following the Algorithm, *not* the prose. >> Note also I put the History transition handling after its parent >> initial.transition handling explicitly, as the parent.initial might actually >> be the one which targeted the History. Therefore their execution order is >> significant. > > initial targetting history… right, I never thought of that. So there is actually > a way to have to run both executable contents. I agree with the order of > execution, of course. > > David
Received on Tuesday, 25 March 2014 08:25:54 UTC