Adrian,
What is all of this, and how does it relate to what I've been working
on in the executioncontext20090716 branch?
It seems like this will:
1. cause some inconvenience now, while more comprehensive changes are
being made in the executioncontext20090716 branch
2. make it a LOT more
I checked out the branch and examined it. After looking over your ideas,
I saw a way to make incremental changes to the trunk - negating the need
for a branch.
The GenericDelegator refactor was done for two reasons:
1. To eliminate the hundreds of references to a concrete class, that
have
I would repository not be a battle ground for conflicting designs, if
David started the work first then that work should be discussed fully
before just dumping code into the trunk that conflicts with what he's
already done in the branch (even if it is in your opinion cleaner).
Regards
I don't see it as a battleground. The changes I made have benefit
outside the work David is doing in the branch.
-Adrian
Scott Gray wrote:
I would repository not be a battle ground for conflicting designs, if
David started the work first then that work should be discussed fully
before just
Yes, that's why I did a similar thing in the branch.
Stepping back a little... please keep in mind that the interface will
not be able to stay in the entity component. Part of the point of
making these interfaces is so that we can have a ExecutionContext that
knows certain things about a
In my implementation, I put the ExecutionContext in framework/base.
I'll work on updating the branch - I caused the problem, so I'll fix it.
-Adrian
David E Jones wrote:
Yes, that's why I did a similar thing in the branch.
Stepping back a little... please keep in mind that the interface
If the ExecutionContext interface is in base and the GenericDelegator
interface is in entity and the ExecutionContext needs to use the
GenericDelegator interface, how will that work?
-David
On Aug 10, 2009, at 5:19 PM, Adrian Crum wrote:
In my implementation, I put the ExecutionContext
lol - while i was driving home I realized that statement would cause confusion.
The basic part of keeping track of the execution path is in framework/base.
Other components extend it to add the higher level artifacts.
Let me fix the branch. Then I'll port my implementation over to it and commit
David,
I think I figured out where the confusion comes from - we have different ideas
of the ExecutionContext role. I see it as a means to keep track of the
execution path, plus a container for frequently used objects. I believe you see
it doing much more than that.
I updated my local copy of
