StaticFactory Extension

Feb 16, 2008 at 3:58 PM
I find interesting you've decided to use the whole Policy+Strategy package for the StaticFactory extension.

IMHO, you could've simply create a IBuildPlanPolicy-derived class that calls the delegate on build up. At least that's what I did and it fits well in the overall architecture and there is no need to place some extension at the "Singleton" stage which seemed strange anyways.
Feb 17, 2008 at 2:31 AM
Edited Feb 17, 2008 at 2:31 AM
Actually, I changed that code two days ago to do exactly what you're suggesting here. The updated version will be available in the next drop.

The extension was written before build plans existed.

Feb 17, 2008 at 4:18 AM
Chris, can you explain the concept behind the Build Plan? I don't recall this in the first Object Builder, so I'm guessing its new.

Feb 17, 2008 at 8:10 AM
I too am interested.

I'm not sure I understand why Strategies and BuildPlanStrategies couldn't be merged into a single set of strategies.

If it was to split whcih strategies are used by DynamicMethodBuildPlanCreatorPolicy and which aren't, then we should have created a view on the existing BuilderContext.Strategies, not define a new strategy placeholder.
Feb 17, 2008 at 8:52 AM
I'll do a more complete explanation on my blog once I've stopped sneezing, but yes, the build plan is new. The basic idea is that the build plan is an object that, when invoked, creates the desired object (the name is analogous to a SQL query plan). The build plan is created via dynamic IL generation. This buys us two major perf benefits. First, it's a generalized cache of all the reflection query info, so you don't have to figure out how to cache per-strategy or scatter policies everywhere, and second, we avoid all the reflection invoke overhead. We're seeing almost an order of magnitude performance improvement using this approach.

The two strategy chains are split because they build different things. The regular strategies are what you're used to with OB. The BuildPlanStrategies generate the dynamic IL used to create the build plan objects. BuildPlanStrategies really aren't regular OB strategies; they don't return an object, for example, instead making calls on the existing IL generator that gets passed through. It might have been cleaner to define a completely different interface, but I needed a pipeline and OB provided a perfectly good one, so I reused it. I think you'd need to make a REALLY strong case for merging the two chains.

This also has a nice side effect that as far as the regular OB chain is concerned, the dynamic IL stuff is completely transparent. You can add preexisting OB strategies (well, if you had preexisting OB2 strategies, anyway) and they'll work just like they did before (as long as they don't depend on policies from the now removed reflection strategies, for example).

We'll talk more about this on Monday I'm sure.

Feb 17, 2008 at 9:56 AM
Yeah... I'll definitely hope we'll have time to talk about it on monday ;)

But for what it's worth... I think you needed a pipeline for the same reasons OB exists: i.e. to Create and Initialize your objets... IL emit or not. IL Emit vs Reflection is only a different strategy. I understand you needed the "DynamicBuildPlanGenerationContext" but this could have been passed along using a policy or a new build key type.

A good reason why I think the're part of the same pipeline is they use the same stages!!

As to the nice side effect that existing strategies can be unaware of the new strategy (IL Emit and new build key), that should prevail whatever the strategy is. You shouldn't develop a strategy and break the IBuildStrategy contract (i.e. change the buildkey down the chain)...

And if BuildPlanStrategies were to exist, I think they should've been extracted into the config part of an extension that deals with DynamicMethod Creation Policy extension.

So my question is more: Could we have done WITHOUT having 2 different pipelines and what would've been the impacts on the design? I don't see many but we'll pair it on monday ;)

I'm sneezing as well. so ttyl...
Feb 17, 2008 at 9:54 PM
Well, they only use the same stages because I'm lazy. ;-) There's absolutely no reason to have the singleton stage in the build plan chain, for example.

Feb 20, 2008 at 7:17 PM
I think I need a concrete example to follow. I'm not really understanding it from this description or the unit tests.