commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 38311] - [scxml] explore strategies for decoupling execution context from representation
Date Fri, 03 Feb 2006 20:45:52 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38311





------- Additional Comments From rahul@apache.org  2006-02-03 21:45 -------
Earlier post re-arranged in response:

(In reply to comment #4)

> In addition, having a class named "Registry" and a class named
> "NotificationRegistry" implies an extension or implementation relationship.

I think this implied relationship based on the names is a convincing argument 
for changing the name (it is a HAS-A rather than IS-A relationship, so the 
current names are ill-suited).


> Here's where I find the naming confusing.  Imagine the documentation for 
this:
> "A state machine is modeled by an instance of SCXML which contains all the
> states and transitions that describe the structure and features of a state
> machine.  When an application needs to execute such a state machine, it will
> need to provide a Registry.  The Registry contains contexts, historical 
state,
> and listeners that are notified when certain events occur during the 
execution
> (or interpretation) of a state machine.  This Registry also contains an 
object
> named NotificationRegistry which is a registry of the aforementioned 
listeners."

Even leaving aside the confusion implied by the naming, the above 
documentation would simply be incorrect. The "Registry" (or whatever the new 
name is, for the sake of this note I'll continue to call it that) is an 
internal structure to the SCXMLExecutor, and the developer/application does 
not need to "provide a Registry" (just a limited number of its parts directly 
via the SCXMLExecutor class API).

See the, albeit incomplete, documentation here:

http://people.apache.org/~rahul/sites/scxml-stateless-model/api-notes/core-
engine.html

The developer provides only the root context, expression evaluator and any 
listeners. The developer does not need to instantiate a Registry and does not 
need to deal with (or be concerned about) the contexts per state or the 
histories (they get assigned and populated by the Registry).


> Anyway, I know I'm being a stickler for the details, but I think of language 
and
> terminology as something that needs to be addresses up front.

This is good for the Commons SCXML component, do continue to be a stickler.


>  I can understand
> that a larger "ExecutionContext" contains a number of objects necessary for
> execution including a sub-contexts that store information particular to each
> state.  I feel less comfortable explaining that the "Registry" contains a 
series
> of objects necessary for execution including a NotificationRegistry and a 
series
> of a Content objects and histories.

But does ExecutionContext have potential for the same confusion w.r.t the 
Context interface, as NotificationRegistry had with Registry? That was my 
brief reference in comment #3.

Suggestions for name:

* ExecutionContext (pending question above)
* ExecutionEnvironment (suggestion from comment #2)
* ExecutionData
* ExecutionInstance
* --something else--

WDYT?



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message