Can't reliably store values (parameters) in container about container HOT 9 CLOSED

The container by definition primarily deals with services as dependencies, it is intended that a class will be given priority.

Take a look here if you want to store values, although I wouldn't recommend it as good practice.

https://github.com/thephpleague/container/blob/master/src/Argument/RawArgument.php

from container.

Would be curious to hear more about why you consider it bad practice to store parameters in the container as this is a standard practice in the symfony community at least.

Are you indicating that

$container->add('my_string_param', new RawArgument('myrawvalue'));

would work? Argument makes some sense in the context of a service definition but not in terms of registering a simple value parameter.

from container.

Just SRP really, a container is in essence a service registry. Values such
as your db connection parameters really should be handled by the
environment.

The only time I can see storing raw values being useful is if you were
using it as a service locater which is considered an anti pattern.

The purpose of the container is to define your dependency map and to wire
those dependencies together.

On Wed, 25 May 2016 17:54 Ben Glassman, [email protected] wrote:

Would be curious to hear more about why you consider it bad practice to
store parameters in the container as this is a standard practice in the
symfony community at least.

Are you indicating that

$container->add('my_string_param', new RawArgument('myrawvalue'));

would work? Argument makes some sense in the context of a service
definition but not in terms of registering a simple value parameter.

—
You are receiving this because you modified the open/close state.

Reply to this email directly or view it on GitHub
#106 (comment)

from container.

I take your point that it is best practice to store sensitive data in
environment variables but there are other values you might store in a
container that are not sensitive or environment-specific. Instantiating
services often requires non-instance values to be injected into
constructors or setter methods so I believe that it does not violate SRP to
have a container be able to store those types of values that are used for
the purpose of instantiating services.

It seems this is not a feature that container will support but I do think
its something that has clear utility as evidenced by its presence in many
other container implementations (symfony, pimple, etc.).

It may be worth including some mention that there is no plan to support
this in the documentation and a recommendation on an alternate approach
since I think it is likely many people trying to use this package may
wonder how they are supposed to handle parameters especially if they are
coming from another container that supports them.

For my purposes I will just be using pimple as it supports this use case.

On Wed, May 25, 2016 at 1:14 PM, Phil Bennett [email protected]
wrote:

Just SRP really, a container is in essence a service registry. Values such
as your db connection parameters really should be handled by the
environment.

The only time I can see storing raw values being useful is if you were
using it as a service locater which is considered an anti pattern.

The purpose of the container is to define your dependency map and to wire
those dependencies together.

On Wed, 25 May 2016 17:54 Ben Glassman, [email protected] wrote:

Would be curious to hear more about why you consider it bad practice to
store parameters in the container as this is a standard practice in the
symfony community at least.

Are you indicating that

$container->add('my_string_param', new RawArgument('myrawvalue'));

would work? Argument makes some sense in the context of a service
definition but not in terms of registering a simple value parameter.

—
You are receiving this because you modified the open/close state.

Reply to this email directly or view it on GitHub
<
#106 (comment)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#106 (comment)

from container.

@benglass

If you intend to share configuration values, have a look at https://github.com/tomphp/config-service-provider - we're using it in production and it works well. Maybe it helps you, too?

from container.

Parameters can be handled either by defining them when you define the
service or by passing them at runtime as a second argument to the get
method. You can even use the raw argument approach I mentioned before and
passing the name of that definition to your service, parameters and
arguments are just that and are handled as such. Services have to take
priority though. Another optioned would be to still store your raw values,
but give them an alias that does not clash with a class name.

On Wed, 25 May 2016 18:27 Ben Glassman, [email protected] wrote:

I take your point that it is best practice to store sensitive data in
environment variables but there are other values you might store in a
container that are not sensitive or environment-specific. Instantiating
services often requires non-instance values to be injected into
constructors or setter methods so I believe that it does not violate SRP
to
have a container be able to store those types of values that are used for
the purpose of instantiating services.

It seems this is not a feature that container will support but I do think
its something that has clear utility as evidenced by its presence in many
other container implementations (symfony, pimple, etc.).

It may be worth including some mention that there is no plan to support
this in the documentation and a recommendation on an alternate approach
since I think it is likely many people trying to use this package may
wonder how they are supposed to handle parameters especially if they are
coming from another container that supports them.

For my purposes I will just be using pimple as it supports this use case.

On Wed, May 25, 2016 at 1:14 PM, Phil Bennett [email protected]
wrote:

Just SRP really, a container is in essence a service registry. Values
such
as your db connection parameters really should be handled by the
environment.

The only time I can see storing raw values being useful is if you were
using it as a service locater which is considered an anti pattern.

The purpose of the container is to define your dependency map and to
wire
those dependencies together.

On Wed, 25 May 2016 17:54 Ben Glassman, [email protected]
wrote:

Would be curious to hear more about why you consider it bad practice
to
store parameters in the container as this is a standard practice in
the
symfony community at least.

Are you indicating that

$container->add('my_string_param', new RawArgument('myrawvalue'));

would work? Argument makes some sense in the context of a service
definition but not in terms of registering a simple value parameter.

—
You are receiving this because you modified the open/close state.

Reply to this email directly or view it on GitHub
<

#106 (comment)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
<
https://github.com/thephpleague/container/issues/106#issuecomment-221641258>

—
You are receiving this because you modified the open/close state.

Reply to this email directly or view it on GitHub
#106 (comment)

from container.

I think the issue I was coming across is that its actually the value that
was clashing with a class name. Prefixing the parameters with "config."
didnt help because the second argument had class_exists() run on it which
in this case it was 'db' and therefore it thought it was a class. Parameter
names are easy to control but values are not.

On Wed, May 25, 2016 at 1:42 PM, Phil Bennett [email protected]
wrote:

Parameters can be handled either by defining them when you define the
service or by passing them at runtime as a second argument to the get
method. You can even use the raw argument approach I mentioned before and
passing the name of that definition to your service, parameters and
arguments are just that and are handled as such. Services have to take
priority though. Another optioned would be to still store your raw values,
but give them an alias that does not clash with a class name.

On Wed, 25 May 2016 18:27 Ben Glassman, [email protected] wrote:

I take your point that it is best practice to store sensitive data in
environment variables but there are other values you might store in a
container that are not sensitive or environment-specific. Instantiating
services often requires non-instance values to be injected into
constructors or setter methods so I believe that it does not violate SRP
to
have a container be able to store those types of values that are used for

the purpose of instantiating services.

It seems this is not a feature that container will support but I do think
its something that has clear utility as evidenced by its presence in many
other container implementations (symfony, pimple, etc.).

It may be worth including some mention that there is no plan to support
this in the documentation and a recommendation on an alternate approach
since I think it is likely many people trying to use this package may
wonder how they are supposed to handle parameters especially if they are
coming from another container that supports them.

For my purposes I will just be using pimple as it supports this use case.

On Wed, May 25, 2016 at 1:14 PM, Phil Bennett [email protected]
wrote:

Just SRP really, a container is in essence a service registry. Values
such
as your db connection parameters really should be handled by the
environment.

The only time I can see storing raw values being useful is if you were
using it as a service locater which is considered an anti pattern.

The purpose of the container is to define your dependency map and to
wire
those dependencies together.

On Wed, 25 May 2016 17:54 Ben Glassman, [email protected]
wrote:

Would be curious to hear more about why you consider it bad practice
to
store parameters in the container as this is a standard practice in
the
symfony community at least.

Are you indicating that

$container->add('my_string_param', new RawArgument('myrawvalue'));

would work? Argument makes some sense in the context of a service
definition but not in terms of registering a simple value parameter.

—
You are receiving this because you modified the open/close state.

Reply to this email directly or view it on GitHub
<

#106 (comment)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
<

#106 (comment)

—
You are receiving this because you modified the open/close state.

Reply to this email directly or view it on GitHub
<
#106 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#106 (comment)

from container.

The easiest way around this is as follows.

$container->add('key', function () {
    return 'value';
});

from container.

@benglass

Realized that, so I opened tomphp/container-configurator#21.

As an alternative to what @philipobenito suggested, how about

use League\Container\Argument\RawArgument;

class StringArgument extends RawArgumentInterface
{
    public function __toString()
    {
        return $this->value;
    }
}

and then

$container->add('key', new StringArgument('value'));

🙎 But, what @philipobenito suggested is a lot better!

from container.