Design Decision Questions

[cocowalla]

I was curious about the rationale for a couple of design decisions that have been pain points for me after trying Lamar on some new projects.

This isn't a criticism BTW, I'm genuinely just curious about the thought process behind these decisions :smiley:

1. Calling Configure on an existing container (I know you're not a fan of this, but it's done a lot) only lets you change config using a Microsoft-style IServiceCollection, rather than the Lamar-style ServiceRegistry. This means you don't get the full power of Lamar (e.g. to add named instances), and is quite limiting

2. Why doesn't INestedContainer implement IContainer? This severely limits how you can configure an existing INestedContainer, and having 2 different types for the 'same' thing is a bit of a pain

[jeremydmiller]

1. It was a dirty workaround to Jasper + ASP.Net Core bootstrapping that I have since made unnecessary
2. There are a few methods on IContainer that shouldn't be valid on a nested container, but I can't say that I remember exactly what those are offhand

[cocowalla]

1. Nice - does that mean we can get some Lamar goodness back on container.Configure at some point?

[jeremydmiller]

Oh, and don't ascribe to conscious thought what's probably the result of accidental evolution;)

The Configure() thing is a huge mess internally and makes the internals crazy hard to deal with if you let folks change the configuration on the fly. With Lamar, I was mostly worried about two things, performance and making the project as easy as possible for me to maintain. To get there, I have purposely sacrificed some of the flexibility that StructureMap had.

[jeremydmiller]

I do remember now, I didn't use SErviceRegistry on purpose because you can't allow users to add any kind of policy.

I'm open to changes though. Like something that's a subset of ServiceRegistry maybe? And I wouldn't mind eliminating INestedContainer anyway