What if one gets aParameterBag(Interface) injected directly? Should it throw a generic error when trying to access any param starting with a dot?

@chalasr I thought about adding some logic in theFrozenParameterBag.
I didn't because:

• with the current implementation, when the container is dumped, the bag is created without the build parameters already (seehttps://github.com/symfony/symfony/blob/6.2/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php#L1567)
• when injectingContainerBagInterface orParameterBagInterface orPsr\Container\ContainerInterface $parameterBag one actually gets the dumped container under the hood, so unless I'm missing something, it's covered already
• I'm not sure we want to add complexity to handle throwing when the container is compiled but not dumped, waiting for some feedback about this.
  Also it would cause problem when the dumper gets the frozen bag as it would get such exception while trying to dump parameter values.

@HeahDude Makes sense, thanks. That could be done later if needed anyways

The next step will likely be to find a way to help the community move from public params to private ones. Here is an idea: when both 'foo' and '.foo' exist, we could consider that this means that using 'foo' at runtime is deprecated. This might help bundles adopt private params.

And another step could be to find a way to completely deprecate a parameter. An idea: params starting-and-ending with a ~ would mean that: get('foo') would lookup for get('foo') and trigger a deprecation. That'd work with private and public params of course.

Before working on this, my intention was to work on deprecating parameters (https://symfony-devs.slack.com/archives/C8WHX21K7/p1663341791619939), so I definitely agree that this should be the next step for another PR :).

I like this idea too 👍🏼 I proposed that8 years ago 👼🏼

We're wondering about how to achieve built-time parameterssince years and this is the best and only actionable idea we've had. I like it a lot personnaly: simple and effective.

Any other vote @symfony/mergers ? I'd like to merge this before#48469 to prevent merge conflicts.

Thank you@HeahDude.