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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
