Hi, Sorry for late response. I've been traveling/moving these past weeks.
To start with: excellent questions! It would be good to get these resolved, for sure.
On 2010-08-07 14.54, Marc Grue wrote:
InteractionContext -> Context -> RoleMap Quote from Tryggve's Artima article about DCI (1): - "... the algorithm and role-to-object mapping are owned by a Context object. The Context "knows" how to find or retrieve the objects that become the actual actors in this Use Case, and "casts" them to the appropriate roles in the Use Case scenarios" (1) The current Context class: - Holds a role-to-object map - Doesn't initiate any role casting. - Doesn't know which roles are "appropriate" for the objects to play - Doesn't know about any Use Case algorithm/scenario It seems confusing to have a class named "Context" that doesn't match the characteristics of the DCI concept "Context" as Trygve describes it above. Since it only holds a role-to-object map, I would suggest to name it a RoleMap. Examples of current use: 1a) StreamflowRootContextFactory.getRoot( Context context ) 2a) Context keeps parent role-to-object maps in a Context parentContext field. 3a) RootContext, line 64: context.set(Object) Same examples after suggested name change: 1b) StreamflowRootContextFactory.getRootContext( RoleMap rolemap ) 2b) RoleMap keeps parent role-to-object maps in a RoleMap parentRoleMap field. 3b) RootContext, line 64: rolemap.set(Object)
Makes perfect sense. Good idea.
Context -> Interactions -> Context - "The interactions that weave their way through the roles are also not new to programming: we call them algorithms" (1) - "... the algorithm and role-to-object mapping are owned by a Context object." (1) The Context *owns* (and initiates) the algorithms/interactions, and it also owns the role-to-object mapping (the RoleMap, through SomeContext.Mixin) but *is* not itself Interactions. If SomeContext extends "Context" instead, it seems natural to say that "we have a Context" which is what SomeContext *is*. Currently: 1a) SomeContext extends Interactions 2a) StreamflowRootContextFactory extends RootInteractionsFactory 3a) In CommandQueryRestlet: - line 164: Context context = new Context(); - line 166: initContext( request, context ) does context.set( Object, roleClass ) - line 172: rootInteractionsFactory.getRoot( context ) returns a RootContext - line 173: context = uow.metaInfo().get( Context.class ) - line 475: getInteractions( Object interactions, segments ) - line 481: if(interactions instanceof SubContexts) - line 485: interactions = ((SubContexts) interactions).context( segment ) - line 502: interactions = interactions.getClass().getMethod( segment ).invoke( interactions ) Suggested: 1b) SomeContext extends Context 2b) StreamflowRootContextFactory extends RootContextFactory 3b) In CommandQueryRestlet: - line 164: RoleMap rolemap = new RoleMap(); - line 166: initContext( request, rolemap ) does rolemap.set( Object, roleClass ) - line 173: rolemap = uow.metaInfo().get( RoleMap.class ) - line 172: rootContextFactory.getRootContext( rolemap ) returns a RootContext - line 475: getCurrentContext( RootContext(?) currentContext, segments ) - line 481: if(currentContext instanceof SubContexts) - line 485: currentContext = ((SubContexts) currentContext).context( segment ) - line 502: currentContext = currentContext.getClass().getMethod( segment ).invoke( currentContext )
Again, makes sense. I was very confused myself with whether it should be Interactions or Context, but with the renaming of Context to RoleMap it becomes more clear what is what.
From here follows naturally:ContextMixin -> InteractionsMixin -> ContextMixin To me it seems confusing that Some*Context*.Mixin extends *Interactions*Mixin and implements Some*Context* that is extending *Interactions*. We kind of have Context-Interactions-Context-Interactions going on :-| SomeContext.Mixin *holds* interaction methods but *is* not itself "interactions" - it's a *SomeContext* implementation (implementing the interactions as a result). To my mind it would therefore be natural to extend a "ContextMixin". Currently: 1a) SomeContext.Mixin extends InteractionsMixin 2a) InteractionsMixin @Uses a (Context)context 3a) InteractionsMixin.subContext(...) sets (Context)context to (Context)subContext = new Context( context ) 4a) InteractionsMixin.subContext( Class<SomeSubContext> interactionsClass ) returns SomeSubContext with subContext injected Suggested: 1b) SomeContext.Mixin extends ContextMixin 2b) ContextMixin @Uses a (RoleMap)roleMap 3b) ContextMixin.subContext(...) sets (RoleMap)roleMap to (RoleMap)currentRoleMap = new RoleMap( roleMap ) 4b) ContextMixin.subContext( Class<SomeSubContext> subContextClass ) returns SomeSubContext with currentRoleMap injected 1a-2a) "context" being a Context suggests that it's "in family with" SomeContext - both "Contexts". But they are not. "context" is a role-to-object map and SomeContext is a Context. 3a) I find it misleading that the method name ("subContext(...)") is equal to the variable name "subContext" holding the role map. 1b-3b) SomeContext.Mixin is now conceptually related to SomeContext (both extends Context*) and roleMap is distinguable as a different concept - a RoleMap. 4) I thinks it's unnecessarily easy to confuse SomeSubContext with subContext. "interactionsClass" is a Context class and "subContext" is a RoleMap in my understanding, and I would therefore would like to name them accordingly. Adopting the name changes would of course have some deep impact on the terminology used throughout the Streamflow project, and any reluctancy to do that would be 100% understandable. But I think it's worth reconsidering the terminology if the Streamflow DCI api is incorporated into the Qi4j libaries/extensions. What do you think?
I think you're spot on, and will make all the suggested changes above before moving the code into Qi4j.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
