Feb 19, 2008 at 6:02 AM
In the BuildPlanStrategies chain, the context gets passed in the "object existing" parameter.

I understang that this parameter being of type "object", it is trivial to pass anything in there but IMHO, it totally reduces "predicatability" of the BuilderStrategy pattern. How do you document this parameter? Sometimes it will contain the object being created, sometimes it will contain the context to create the object?

I think we'd be better off defining a new BuildKey that has the name, the type and the context all in one.
Feb 21, 2008 at 8:14 PM
Defining a new build key is problematic; it's used to look up policies, and has to compare by value. Having extra stuff in there makes it harder to get right.

I don't see too much confusion. In the regular strategy chain, existing is always the object that's being built. In the build plan chain, existing is always the IL generation context.
Feb 21, 2008 at 8:43 PM
Yeah you're right. It makes it harder, not impossible but definitely harder and not any cleaner.

Maybe the Additional (Transient) Data generic dictionary could make it cleaner too.

Not that I'm trying to find usages to it so I can justify it and move it to a workitem :)

However, I understand that BuildPlan Strategies live in the Compile Time world and therefore cannot receive an "existing" build instance but only a context to build the object. I was just saying the definition of this parameter is documented as an existing instance, not a placeholder for anything a strategy might need (like Thread.Start delegate can receive "any" data)

That being said, having to stack rank it, my vote wouldn't be lost on this one.