You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Hallvard Trætteberg (JIRA)" <ji...@apache.org> on 2006/10/02 15:16:02 UTC
[jira] Created: (SCXML-27) Improve possibility to extending
(subclassing) the default semantics
Improve possibility to extending (subclassing) the default semantics
--------------------------------------------------------------------
Key: SCXML-27
URL: http://issues.apache.org/jira/browse/SCXML-27
Project: Commons SCXML
Issue Type: Improvement
Affects Versions: 0.5
Reporter: Hallvard Trætteberg
I've extended the default SCXML semantics (subclassed SCXMLSemanticsImpl) with a more flexible event matching method. However, this required copying a lot of code from SCXMLSemanticsImpl, just to replace the event matching method. The problem was that the eventMatch method takes String and Set arguments, with no way to get at the Transition who's event is to be tested. I copied the relevant code and replaced eventMatch(String,Set) with eventMatch(Transition,Set), to make it more flexible. I ask that this change is made to SCXMLSemanticsImpl, to better support overriding.
The flexibility I've added is to use regular expressions for matching, and since this happens often, I wanted to cache the compiled pattern. The natural place to do this is the Transition, so I subclassed the Transition class, included a field for holding the compiled pattern and made sure to use this subclass whenever a regexp was needed. Then in the modified eventMatch code, I check whether the Transition is of this subclass and used the cache to improve performance.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Resolved: (SCXML-27) Improve possibility to extending
(subclassing) the default semantics
Posted by "Rahul Akolkar (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SCXML-27?page=all ]
Rahul Akolkar resolved SCXML-27.
--------------------------------
Resolution: Won't Fix
Its probably the natural place to put the compiled pattern, but subclassing the Transition class probably requires changes in other places (we generally do not recommend subclassing anything in the model package, since it can have collateral in the digester, semantics etc.)
Might be best to maintain an independent cache here.
> Improve possibility to extending (subclassing) the default semantics
> --------------------------------------------------------------------
>
> Key: SCXML-27
> URL: http://issues.apache.org/jira/browse/SCXML-27
> Project: Commons SCXML
> Issue Type: Improvement
> Affects Versions: 0.5
> Reporter: Hallvard Trætteberg
>
> I've extended the default SCXML semantics (subclassed SCXMLSemanticsImpl) with a more flexible event matching method. However, this required copying a lot of code from SCXMLSemanticsImpl, just to replace the event matching method. The problem was that the eventMatch method takes String and Set arguments, with no way to get at the Transition who's event is to be tested. I copied the relevant code and replaced eventMatch(String,Set) with eventMatch(Transition,Set), to make it more flexible. I ask that this change is made to SCXMLSemanticsImpl, to better support overriding.
> The flexibility I've added is to use regular expressions for matching, and since this happens often, I wanted to cache the compiled pattern. The natural place to do this is the Transition, so I subclassed the Transition class, included a field for holding the compiled pattern and made sure to use this subclass whenever a regexp was needed. Then in the modified eventMatch code, I check whether the Transition is of this subclass and used the cache to improve performance.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (SCXML-27) Improve possibility to extending
(subclassing) the default semantics
Posted by "Hallvard Trætteberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SCXML-27?page=comments#action_12439307 ]
Hallvard Trætteberg commented on SCXML-27:
------------------------------------------
My suggestion was not to directly support subclassing of Transition or caching of regexp patterns, but to refactor SCXMLSemanticsImpl so extending the event matching strategy is easy for a subclass. As mentioned, for such a simple case, I had to copy the whole filterTransitionsSet method from SCXMLSemanticsImpl to get hold of the Transition, as it was needed by the event matching strategy. If the eventMatch method took the Transition as the first argument, instead of its event, an overriding method would have more information.
I have a second use case for this. I also use the scripting language for event matching. More specifically, I allow referring to contextual objects, so the event matching method may match against "any event generated from object x", where object x is an object in the context of the transition. Without knowing which Transition the event is attached to, the expression cannot be evaluated.
> Improve possibility to extending (subclassing) the default semantics
> --------------------------------------------------------------------
>
> Key: SCXML-27
> URL: http://issues.apache.org/jira/browse/SCXML-27
> Project: Commons SCXML
> Issue Type: Improvement
> Affects Versions: 0.5
> Reporter: Hallvard Trætteberg
>
> I've extended the default SCXML semantics (subclassed SCXMLSemanticsImpl) with a more flexible event matching method. However, this required copying a lot of code from SCXMLSemanticsImpl, just to replace the event matching method. The problem was that the eventMatch method takes String and Set arguments, with no way to get at the Transition who's event is to be tested. I copied the relevant code and replaced eventMatch(String,Set) with eventMatch(Transition,Set), to make it more flexible. I ask that this change is made to SCXMLSemanticsImpl, to better support overriding.
> The flexibility I've added is to use regular expressions for matching, and since this happens often, I wanted to cache the compiled pattern. The natural place to do this is the Transition, so I subclassed the Transition class, included a field for holding the compiled pattern and made sure to use this subclass whenever a regexp was needed. Then in the modified eventMatch code, I check whether the Transition is of this subclass and used the cache to improve performance.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (SCXML-27) Improve possibility to extending
(subclassing) the default semantics
Posted by "Rahul Akolkar (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SCXML-27?page=comments#action_12439571 ]
Rahul Akolkar commented on SCXML-27:
------------------------------------
Let me state my assertions behind resolving this as won't fix:
a) The class in question has non-trivial functionality
b) We tried to make it pluggable, exactly for these kind of usecases
c) Custom semantics is considered advanced API for the library
d) The existing method signatures and call stack cannot be compromised
e) Because of (a) and (d), some (or many) cases might require subclasses to indulge in copious copy-paste to find the correct insertion points
f) I personally expect advanced users to be somewhat more tolerant than casual users
g) Making a particular change that makes sense for any one usecase does not solve this issue eternally
To reopen this ticket, therefore, we need a complete proposal stating how:
a) Subclassing convenience has improved for many (if not all) usecases (preferred way to illustrate is test cases)
b) All existing API contracts are preserved
c) The changes (additions, really) constitute the minimal essential set
This is not to say your suggestion may not have merit for your usecase, it does, but these are the (more important) broader constraints.
> Improve possibility to extending (subclassing) the default semantics
> --------------------------------------------------------------------
>
> Key: SCXML-27
> URL: http://issues.apache.org/jira/browse/SCXML-27
> Project: Commons SCXML
> Issue Type: Improvement
> Affects Versions: 0.5
> Reporter: Hallvard Trætteberg
>
> I've extended the default SCXML semantics (subclassed SCXMLSemanticsImpl) with a more flexible event matching method. However, this required copying a lot of code from SCXMLSemanticsImpl, just to replace the event matching method. The problem was that the eventMatch method takes String and Set arguments, with no way to get at the Transition who's event is to be tested. I copied the relevant code and replaced eventMatch(String,Set) with eventMatch(Transition,Set), to make it more flexible. I ask that this change is made to SCXMLSemanticsImpl, to better support overriding.
> The flexibility I've added is to use regular expressions for matching, and since this happens often, I wanted to cache the compiled pattern. The natural place to do this is the Transition, so I subclassed the Transition class, included a field for holding the compiled pattern and made sure to use this subclass whenever a regexp was needed. Then in the modified eventMatch code, I check whether the Transition is of this subclass and used the cache to improve performance.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org