Unsealing Builders and Configuration #829
Replies: 1 comment
-
Yes, that is something we briefly discussed and have been giving it a lot of thought (and still do). While we would like to provide a pre-configured instance that is ready to use upon creation, including support for inheritance, developers who extend modules may encounter a null reference exception due to a virtual member call. To prevent developers from encountering this issue, we have decided to keep the builders sealed for now until we can come up with a better design. We are open to discussing proposals and all ideas that could improve the design. I have a few ideas in mind, but I need to test them first.
Additionally, are these the only use cases for which you would like to unseal the classes? I ask because I would like to understand if there are other cases we may be overlooking. If you need multiple instances of the same or similar configurations, you can call var sharedBuilder = new ContainerBuilder()
.WithImage(CommonImages.Alpine)
.WithEntrypoint(CommonCommands.SleepInfinity);
var containerA = sharedBuilder
.WithEnvironment("DOTNET_NOLOGO", "true")
.Build();
var containerB = sharedBuilder
.WithEnvironment("DOTNET_NOLOGO", "false")
.Build();
var containerC = sharedBuilder.Build();
var containerD = sharedBuilder.Build();
var containerE = sharedBuilder.Build(); |
Beta Was this translation helpful? Give feedback.
-
Any chance with the new module-specific builders/configuration/etc. in 3.0.0 that these types will get unsealed? It would be nice to override/extend from them to create our own customized versions that we can use throughout out projects. For example we always override the postgres image and user name; it'd be nice if we could have our own module without have to re-create it entirely from scratch.
The documentation makes it sound like you should be able to extend (inherit) from the builder and configuration classes, however everything is sealed.
Beta Was this translation helpful? Give feedback.
All reactions