Some random thoughts about this feature:

How should parameters be consumed by applications?

In a perfect world, parameters are only consumed by compiler passes and injected via DI into services. In both cases, we won't need them anymore once the container is dumped.

However, it might be helpful to keep all parameters in dev for debugging purposes. Container::getParameter() could then issue a more sepecific exception when attempting to access inlined parameters and those parameters could be queried by the debug:container command.

Are there any parameters that we want to keep in an optimized container?

Personally, I'm using getParameter() at runtime only in legacy applications that haven't been developed around the DI pattern. Here, I need to access kernel.project_dir quite frequently. I think if we removed that parameter from the final container, we would cause quite some migration efforts for little benefit. Do we have other parameters like that?

What doe we try to achieve by introducing a second type of parameter?

Performance? I doubt that we're getting faster since parameters are inlined into the dumped service factories already.
Container size? Would the impact really be that big?
Reduce memory footprint? I think we can save a couple of KiB this way, but not much more.
Hide temporary values that developers should not depend on?

How would we set such a compile-time parameter on the container builder?

$containerBuilder->setParameter('my_param', 'my value', true) // A
$containerBuilder->setCompileTimeParameter('my_param', 'some value') // B

Personally, I'd prefer version B at the moment.

How would be define such a parameter in YAML?

# A
parameters:
    my_public_param: some value
    my_param:
        value: some value
        scope: compile_time

# B
parameters:
    my_public_param: some value

compile_time_parameters:
    my_param: some value

# C
parameters:
    _compile_time:
        my_param: some value
    my_public_param: some value

# D
parameters:
    my_public_param: some value
    my_param: !compile_time some value

How would the migration path look like?

If we mark existing parameters as compile-time-only we need a migration path for applications that access those via getParameter(). Should we offer a way for applications to make a compile-time parameter available after compilation?

Uh oh!

Make some parameters available only at compile time #36831

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions